Message-ID: <62bdb238-7440-451b-84ef-79f846b10ba0@foss.st.com>
Date: Tue, 16 Sep 2025 15:26:47 +0200
From: Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>
To: Sumit Garg <sumit.garg@...nel.org>
CC: Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier
	<mathieu.poirier@...aro.org>,
        Jens Wiklander <jens.wiklander@...aro.org>,
        Rob
 Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor
 Dooley <conor+dt@...nel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <op-tee@...ts.trustedfirmware.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH v19 4/6] dt-bindings: remoteproc: Add compatibility for
 TEE support

Hello Sumit,

On 9/16/25 11:14, Sumit Garg wrote:
> Hi Arnaud,
>
> First of all apologies for such a late review comment as previously I
> wasn't CCed or involved in the review of this patch-set. In case any of
> my following comments have been discussed in the past then feel free to
> point me at relevant discussions.

No worries, there are too many versions of this series to follow all the
past discussions. I sometimes have difficulty remembering all the
discussions myself :)

>
> On Wed, Jun 25, 2025 at 11:40:26AM +0200, 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).
> Having a DT based compatible for a TEE service to me just feels like it
> is redundant here. I can see you have also used a TEE bus based device
> too but that is not being properly used. I know subsystems like
> remoteproc, SCMI and others heavily rely on DT to hardcode properties of
> system firmware which are rather better to be discovered dynamically.
>
> So I have an open question for you and the remoteproc subsystem
> maintainers being:
>
> Is it feasible to rather leverage the benefits of a fully discoverable
> TEE bus rather than relying on platform bus/ DT to hardcode firmware
> properties?

The discoverable TEE bus does not works if the remoteproc is probed
before the OP-TEE bus, in such case  no possibility to know if the TEE
TA is not yet available or not available at all.
This point is mentioned in a comment in rproc_tee_register().

Then, it is not only a firmware property in our case. Depending on the
compatible string, we manage the hardware differently. The same compatibles
are used in both OP-TEE and Linux. Based on the compatible, we can assign
memories, clocks, and resets to either the secure or non-secure context.
This approach is implemented on the STM32MP15 and STM32MP2x platforms.

More details are available in the ST WIKI:
https://wiki.st.com/stm32mpu/wiki/OP-TEE_remoteproc_framework_overview#Device_tree_configuration
https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview#Device_tree_configuration

>
>> For instance, this compatible is used in both the Linux and OP-TEE device
>> trees:
>> - In OP-TEE, a node is defined in the device tree with the
>>    "st,stm32mp1-m4-tee" compatible to support signed remoteproc firmware.
>>    Based on DT properties, the OP-TEE remoteproc framework is initiated to
>>    expose a trusted application service to authenticate and load the remote
>>    processor firmware provided by the Linux remoteproc framework, as well
>>    as to start and stop the remote processor.
>> - In Linux, when the compatibility is set, the Cortex-M resets should not
>>    be declared in the device tree. In such a configuration, the reset is
>>    managed by the OP-TEE remoteproc driver and is no longer accessible from
>>    the Linux kernel.
>>
>> Associated with this new compatible, add the "st,proc-id" property to
>> identify the remote processor. This ID is used to define a unique ID,
>> common between Linux, U-Boot, and OP-TEE, to identify a coprocessor.
> This "st,proc-id" is just one such property which can rather be directly
> probed from the TEE/OP-TEE service rather than hardcoding it in DT here.
Do you mean a topology discovery mechanism through the TEE remoteproc
service?

For the STM32MP15, it could work since we have only one remote processor.
However, this is not the case for the STM32MP25, which embeds both a
Cortex-M33 and a Cortex-M0.

Could you please elaborate on how you see the support of multiple remote
processors without using an hardcoded identifier?

> I think the same will apply to other properties as well.
Could you details the other properties you have in mind?

Thanks,
Arnaud

>
> -Sumit
>
>> This ID will be used in requests to the OP-TEE remoteproc Trusted
>> Application to specify the remote processor.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>
>> Reviewed-by: Rob Herring (Arm) <robh@...nel.org>
>> ---
>>   .../bindings/remoteproc/st,stm32-rproc.yaml   | 58 ++++++++++++++++---
>>   1 file changed, 50 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
>> index 843679c557e7..58da07e536fc 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
>> +    description:
>> +      Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by non-secure context
>> +      Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by secure context
>>   
>>     reg:
>>       description:
>> @@ -43,6 +48,10 @@ properties:
>>             - description: The offset of the hold boot setting register
>>             - description: The field mask of the hold boot
>>   
>> +  st,proc-id:
>> +    description: remote processor identifier
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>>     st,syscfg-tz:
>>       deprecated: true
>>       description:
>> @@ -146,21 +155,43 @@ properties:
>>   required:
>>     - compatible
>>     - reg
>> -  - resets
>>   
>>   allOf:
>>     - if:
>>         properties:
>> -        reset-names:
>> -          not:
>> -            contains:
>> -              const: hold_boot
>> +        compatible:
>> +          contains:
>> +            const: st,stm32mp1-m4
>>       then:
>> +      if:
>> +        properties:
>> +          reset-names:
>> +            not:
>> +              contains:
>> +                const: hold_boot
>> +      then:
>> +        required:
>> +          - st,syscfg-holdboot
>> +      else:
>> +        properties:
>> +          st,syscfg-holdboot: false
>> +        required:
>> +          - reset-names
>>         required:
>> -        - st,syscfg-holdboot
>> -    else:
>> +        - resets
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: st,stm32mp1-m4-tee
>> +    then:
>>         properties:
>>           st,syscfg-holdboot: false
>> +        reset-names: false
>> +        resets: false
>> +      required:
>> +        - st,proc-id
>>   
>>   additionalProperties: false
>>   
>> @@ -192,5 +223,16 @@ examples:
>>         st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
>>         st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
>>       };
>> +  - |
>> +    #include <dt-bindings/reset/stm32mp1-resets.h>
>> +    m4@...00000 {
>> +      compatible = "st,stm32mp1-m4-tee";
>> +      reg = <0x10000000 0x40000>,
>> +            <0x30000000 0x40000>,
>> +            <0x38000000 0x10000>;
>> +      st,proc-id = <0>;
>> +      st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
>> +      st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
>> +    };
>>   
>>   ...
>> -- 
>> 2.25.1
>>
>>

Powered by blists - more mailing lists