From: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>,
Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Jens Wiklander <jens.wiklander@linaro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add compatibility for TEE support
Date: Tue, 30 Jan 2024 11:21:56 -0600 [thread overview]
Message-ID: <20240130172156.GA2008728-robh@kernel.org> (raw)
In-Reply-To: <75429209-8f30-4880-8f92-ecb3cf90ae33@linaro.org>
On Fri, Jan 26, 2024 at 12:03:25PM +0100, Krzysztof Kozlowski wrote:
> On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> > where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> > (TEE).
> > For instance, this compatible is used in both the Linux and OP-TEE
> > device-tree:
> > - In OP-TEE, a node is defined in the device tree with the
> > st,stm32mp1-m4-tee to support signed remoteproc firmware.
> > Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> > the firmware.
> > - On Linux, when the compatibility is set, the Cortex-M resets should not
> > be declared in the device tree.
> >
> > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> > ---
> > V1 to V2 updates
> > - update "st,stm32mp1-m4" compatible description to generalize
> > - remove the 'reset-names' requirement in one conditional branch, as the
> > property is already part of the condition test.
> > ---
> > .../bindings/remoteproc/st,stm32-rproc.yaml | 52 +++++++++++++++----
> > 1 file changed, 43 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > index 370af61d8f28..6af821b15736 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > @@ -16,7 +16,12 @@ maintainers:
> >
> > properties:
> > compatible:
> > - const: st,stm32mp1-m4
> > + enum:
> > + - st,stm32mp1-m4
> > + - st,stm32mp1-m4-tee
>
> The patch looks good to me, but I wonder about this choice of two
> compatibles.
>
> Basically this is the same hardware with the same interface, but two
> compatibles to differentiate a bit different firmware setup. We have
> already such cases for Qualcomm [1] [2] and new ones will be coming. [3]
>
> I wonder whether this should be rather the same compatible with
> additional property, e.g. "st,tee-control" or "remote-control".
>
> [1]
> https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml#L54
>
> [2]
> https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/net/qcom,ipa.yaml#L129
> (that's a bit different)
>
> [3] https://lore.kernel.org/linux-devicetree/20240124103623.GJ4906@thinkpad/
>
> @Rob,
> Any general guidance for this and Qualcomm?
I think we have cases using compatible already as well. Either way is
fine with me.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add compatibility for TEE support
Date: Tue, 30 Jan 2024 11:21:56 -0600 [thread overview]
Message-ID: <20240130172156.GA2008728-robh@kernel.org> (raw)
In-Reply-To: <75429209-8f30-4880-8f92-ecb3cf90ae33@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]
On Fri, Jan 26, 2024 at 12:03:25PM +0100, Krzysztof Kozlowski wrote:
> On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> > where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> > (TEE).
> > For instance, this compatible is used in both the Linux and OP-TEE
> > device-tree:
> > - In OP-TEE, a node is defined in the device tree with the
> > st,stm32mp1-m4-tee to support signed remoteproc firmware.
> > Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> > the firmware.
> > - On Linux, when the compatibility is set, the Cortex-M resets should not
> > be declared in the device tree.
> >
> > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> > ---
> > V1 to V2 updates
> > - update "st,stm32mp1-m4" compatible description to generalize
> > - remove the 'reset-names' requirement in one conditional branch, as the
> > property is already part of the condition test.
> > ---
> > .../bindings/remoteproc/st,stm32-rproc.yaml | 52 +++++++++++++++----
> > 1 file changed, 43 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > index 370af61d8f28..6af821b15736 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > @@ -16,7 +16,12 @@ maintainers:
> >
> > properties:
> > compatible:
> > - const: st,stm32mp1-m4
> > + enum:
> > + - st,stm32mp1-m4
> > + - st,stm32mp1-m4-tee
>
> The patch looks good to me, but I wonder about this choice of two
> compatibles.
>
> Basically this is the same hardware with the same interface, but two
> compatibles to differentiate a bit different firmware setup. We have
> already such cases for Qualcomm [1] [2] and new ones will be coming. [3]
>
> I wonder whether this should be rather the same compatible with
> additional property, e.g. "st,tee-control" or "remote-control".
>
> [1]
> https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml#L54
>
> [2]
> https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/net/qcom,ipa.yaml#L129
> (that's a bit different)
>
> [3] https://lore.kernel.org/linux-devicetree/20240124103623.GJ4906(a)thinkpad/
>
> @Rob,
> Any general guidance for this and Qualcomm?
I think we have cases using compatible already as well. Either way is
fine with me.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>,
Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Jens Wiklander <jens.wiklander@linaro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add compatibility for TEE support
Date: Tue, 30 Jan 2024 11:21:56 -0600 [thread overview]
Message-ID: <20240130172156.GA2008728-robh@kernel.org> (raw)
In-Reply-To: <75429209-8f30-4880-8f92-ecb3cf90ae33@linaro.org>
On Fri, Jan 26, 2024 at 12:03:25PM +0100, Krzysztof Kozlowski wrote:
> On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> > where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> > (TEE).
> > For instance, this compatible is used in both the Linux and OP-TEE
> > device-tree:
> > - In OP-TEE, a node is defined in the device tree with the
> > st,stm32mp1-m4-tee to support signed remoteproc firmware.
> > Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> > the firmware.
> > - On Linux, when the compatibility is set, the Cortex-M resets should not
> > be declared in the device tree.
> >
> > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> > ---
> > V1 to V2 updates
> > - update "st,stm32mp1-m4" compatible description to generalize
> > - remove the 'reset-names' requirement in one conditional branch, as the
> > property is already part of the condition test.
> > ---
> > .../bindings/remoteproc/st,stm32-rproc.yaml | 52 +++++++++++++++----
> > 1 file changed, 43 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > index 370af61d8f28..6af821b15736 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> > @@ -16,7 +16,12 @@ maintainers:
> >
> > properties:
> > compatible:
> > - const: st,stm32mp1-m4
> > + enum:
> > + - st,stm32mp1-m4
> > + - st,stm32mp1-m4-tee
>
> The patch looks good to me, but I wonder about this choice of two
> compatibles.
>
> Basically this is the same hardware with the same interface, but two
> compatibles to differentiate a bit different firmware setup. We have
> already such cases for Qualcomm [1] [2] and new ones will be coming. [3]
>
> I wonder whether this should be rather the same compatible with
> additional property, e.g. "st,tee-control" or "remote-control".
>
> [1]
> https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml#L54
>
> [2]
> https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/net/qcom,ipa.yaml#L129
> (that's a bit different)
>
> [3] https://lore.kernel.org/linux-devicetree/20240124103623.GJ4906@thinkpad/
>
> @Rob,
> Any general guidance for this and Qualcomm?
I think we have cases using compatible already as well. Either way is
fine with me.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-30 17:21 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 10:04 [PATCH v2 0/4] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
2024-01-18 10:05 ` Arnaud Pouliquen
2024-01-18 10:04 ` Arnaud Pouliquen
2024-01-18 10:04 ` [PATCH v2 1/4] remoteproc: Add TEE support Arnaud Pouliquen
2024-01-18 10:06 ` Arnaud Pouliquen
2024-01-18 10:04 ` Arnaud Pouliquen
2024-01-25 18:55 ` Mathieu Poirier
2024-01-25 18:55 ` Mathieu Poirier
2024-01-25 18:55 ` Mathieu Poirier
2024-01-26 13:39 ` Arnaud POULIQUEN
2024-01-26 13:39 ` Arnaud POULIQUEN
2024-01-26 13:39 ` Arnaud POULIQUEN
2024-01-26 16:04 ` Mathieu Poirier
2024-01-26 16:04 ` Mathieu Poirier
2024-01-26 16:04 ` Mathieu Poirier
2024-01-26 18:03 ` Mathieu Poirier
2024-01-26 18:03 ` Mathieu Poirier
2024-01-26 18:03 ` Mathieu Poirier
2024-01-29 18:55 ` Mathieu Poirier
2024-01-29 18:55 ` Mathieu Poirier
2024-01-29 18:55 ` Mathieu Poirier
2024-01-30 8:15 ` Arnaud POULIQUEN
2024-01-30 8:16 ` Arnaud POULIQUEN
2024-01-30 8:15 ` Arnaud POULIQUEN
2024-01-18 10:04 ` [PATCH v2 2/4] dt-bindings: remoteproc: Add compatibility for " Arnaud Pouliquen
2024-01-18 10:07 ` Arnaud Pouliquen
2024-01-18 10:04 ` Arnaud Pouliquen
2024-01-26 11:03 ` Krzysztof Kozlowski
2024-01-26 11:03 ` Krzysztof Kozlowski
2024-01-26 11:03 ` Krzysztof Kozlowski
2024-01-26 13:59 ` Arnaud POULIQUEN
2024-01-26 13:59 ` Arnaud POULIQUEN
2024-01-26 13:59 ` Arnaud POULIQUEN
2024-01-30 17:21 ` Rob Herring [this message]
2024-01-30 17:21 ` Rob Herring
2024-01-30 17:21 ` Rob Herring
2024-01-30 17:51 ` Rob Herring
2024-01-30 17:51 ` Rob Herring
2024-01-30 17:51 ` Rob Herring
2024-02-13 15:38 ` Arnaud POULIQUEN
2024-02-13 15:39 ` Arnaud POULIQUEN
2024-02-13 15:38 ` Arnaud POULIQUEN
2024-01-18 10:04 ` [PATCH v2 3/4] remoteproc: stm32: Create sub-functions to request shutdown and release Arnaud Pouliquen
2024-01-18 10:08 ` Arnaud Pouliquen
2024-01-18 10:04 ` Arnaud Pouliquen
2024-01-18 10:04 ` [PATCH v2 4/4] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware Arnaud Pouliquen
2024-01-18 10:09 ` Arnaud Pouliquen
2024-01-18 10:04 ` Arnaud Pouliquen
2024-01-26 17:11 ` Mathieu Poirier
2024-01-26 17:11 ` Mathieu Poirier
2024-01-26 17:11 ` Mathieu Poirier
2024-01-30 9:13 ` Arnaud POULIQUEN
2024-01-30 9:14 ` Arnaud POULIQUEN
2024-01-30 9:13 ` Arnaud POULIQUEN
2024-01-31 18:52 ` Mathieu Poirier
2024-01-31 18:52 ` Mathieu Poirier
2024-01-31 18:52 ` Mathieu Poirier
2024-02-01 15:06 ` Arnaud POULIQUEN
2024-02-01 15:06 ` Arnaud POULIQUEN
2024-02-01 15:06 ` Arnaud POULIQUEN
2024-02-01 16:02 ` Mathieu Poirier
2024-02-01 16:02 ` Mathieu Poirier
2024-02-01 16:02 ` Mathieu Poirier
2024-02-01 18:33 ` Arnaud POULIQUEN
2024-02-01 18:34 ` Arnaud POULIQUEN
2024-02-01 18:33 ` Arnaud POULIQUEN
2024-02-02 19:53 ` Mathieu Poirier
2024-02-02 19:53 ` Mathieu Poirier
2024-02-02 19:53 ` Mathieu Poirier
2024-02-05 9:13 ` Arnaud POULIQUEN
2024-02-05 9:14 ` Arnaud POULIQUEN
2024-02-05 9:13 ` Arnaud POULIQUEN
2024-02-13 15:47 ` [Linux-stm32] " Arnaud POULIQUEN
2024-02-13 15:48 ` Arnaud POULIQUEN
2024-02-13 15:47 ` Arnaud POULIQUEN
2024-02-13 18:39 ` Mathieu Poirier
2024-02-13 18:39 ` Mathieu Poirier
2024-02-13 18:39 ` Mathieu Poirier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240130172156.GA2008728-robh@kernel.org \
--to=robh@kernel.org \
--cc=andersson@kernel.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jens.wiklander@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mathieu.poirier@linaro.org \
--cc=op-tee@lists.trustedfirmware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.