Re: [PATCH v21 2/6] dt-bindings: remoteproc: Add STM32 TEE-controlled rproc binding

[Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>]

On 3/19/26 11:41, Krzysztof Kozlowski wrote:
> On 19/03/2026 11:31, Arnaud POULIQUEN wrote:
>> Hello Krzysztof,
>>
>>
>> On 3/19/26 09:06, Krzysztof Kozlowski wrote:
>>> On Tue, Mar 17, 2026 at 07:03:23PM +0100, Arnaud Pouliquen wrote:
>>>> Add a Device Tree binding for the STM32 remote processor controlled
>>>> via a Trusted Application running in OP-TEE.
>>>> This binding describes the interface and properties required for STM32MP
>>>> remoteproc instances managed by the TEE rproc service, including a
>>>> linkage to the TEE backend through the property "rproc-tee-phandle".
>>>>
>>>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> ---
>>>> V21 updates:
>>>> - the m4 node is no more declared as a child of the optee-rproc node
>>>> - "rproc-tee-phandle" property is introduced to reference the optee-rproc
>>>> ---
>>>>    .../remoteproc/st,stm32-rproc-tee.yaml        | 108 ++++++++++++++++++
>>>>    1 file changed, 108 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
>>>> new file mode 100644
>>>> index 000000000000..ca4dd1c8e7b0
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
>>>> @@ -0,0 +1,108 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/remoteproc/st,stm32-rproc-tee.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: STMicroelectronics STM32 remote processor controlled via TEE
>>>> +
>>>> +maintainers:
>>>> +  - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>>>> +
>>>> +description: |
>>>> +  STM32MP remote processor controlled by a Trusted Application
>>>> +  running in OP-TEE. This node is a child of the TEE remoteproc service
>>>> +  (UUID 80a4c275-0a47-4905-8285-1486a9771a08) and exposes a remoteproc
>>>> +  instance managed by the Linux remoteproc core via the TEE rproc service.
>>>> +
>>>> +  Firmware loading, authentication and remote processor start/stop are managed
>>>> +  by the TEE application. The STM32-specific driver handles platform resources
>>>> +  such as the mailboxes and reserved-memory.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: st,stm32mp1-m4-tee
>>>
>>> Drop "tee", it suggests that compatible is tied to implementation of FW
>>> you put there.
>>
>> The "st,stm32mp1-m4" compatible string already exists in
> 
> Then probably this binding needs changes, because in general you should
> not have two compatibles for the same hardware. Maybe that's special
> case, but then needs explanations in commit msg why is that.
> 
>> drivers/remoteproc/stm32_rproc.c, and "st,stm32mp1-m4-tee" compatible is
>> upstreamed in OP-TEE.
> 
> That is not our problem and strong no-go. Other projects are supposed to
> participate in upstream bindings review and take the bindings once they
> are reviewed and accepted here. If they take without review, it's their
> problem.
> 
> Imagine that: some whatever project takes whatever crap (not saying
> Optee is like that, just imagine for sake of discussion) and then you
> send bindings to upstream and claim "that project took it, so you must
> do as well". Great loophole to squeeze poor stuff to the kernel, so any
> such argument is for me a warning sign.
> 
> 
>>
>> Notice that I have also the stm32mp2 SoC to upstream expecting to have
>> similar compatible:
>> - st,stm32mp1-m33
>> - st,stm32mp2-m33-tee
>>
>> Depending on the compatible string, the hardware behavior changes.
>> With the "xxxx-tee" compatible, OP-TEE also manages the isolation of
>> remote processor resources (memory, clock reset, peripherals).
>> Without the "xxxx-tee" compatible, OP-TEE have to ensure that the Linux
>> has the good access right to manage the remote processor.
> 
> Still the same device, no?
> 
> You can have a property defining how Linux should access such device,
> e.g. because FW does this and that.
> 
>>
>> For instance if st,stm32mp1-m4-tee is set instead of st,stm32mp1-m4, on
>> linux side
>> - only memory regions used for IPC should be declared
>> - memory regions containing the remote firmware must not be declared as
>> not accessible by the Linux ( managed by OP-TEE).
>> - resets must not be declared ( managed by OP-TEE)
>>
>> You probably don't remember, as it was a long time ago, but we already
>> discussed this point with Rob[1].
>> [1] https://lkml.org/lkml/2024/1/18/100
>>
>> Do it still reasonable to you and Rob or should we find an alternative?
> 
> Get ack from Rob then.

A previous acknowledgment from Rob was given here: 
https://lkml.org/lkml/2024/2/22/1264.

What frustrates me is that, if the compatible usage is no longer 
accepted, I have lost time basing all my other versions on this 
assumption. But that’s part of the game, and this series is already a 
concatenation of redesigns resulting in version V21.

My expectation is simply that you and Rob provide me with a clear 
direction to move forward.

The compatible string is one topic; I also need an acknowledgment or 
rejection of the concept of using a phandle to link the remoteproc 
driver with the TEE service.

Thanks and regards,
Arnaud

> 
> 
> Best regards,
> Krzysztof