Re: [Linux-stm32] [PATCH v20 1/6] dt-bindings: firmware: Add TEE remoteproc service binding

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

Hello Rob, Sumit,

Just a gentle reminder. Could you please provide your advice or a 
conclusion on the direction we should take for the DT declaration? I 
need your input to be able to move forward.

Thanks and regards,
Arnaud

On 1/13/26 10:20, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 1/5/26 08:37, Sumit Garg wrote:
>> On Fri, Jan 02, 2026 at 04:17:27PM -0600, Rob Herring wrote:
>>> On Tue, Dec 30, 2025 at 5:10 AM Sumit Garg <sumit.garg@kernel.org> 
>>> wrote:
>>>>
>>>> On Mon, Dec 29, 2025 at 05:25:30PM -0600, Rob Herring wrote:
>>>>> On Wed, Dec 17, 2025 at 04:39:12PM +0100, Arnaud Pouliquen wrote:
>>>>>> Add a device tree binding for the TEE-based remote processor control
>>>>>> service implemented as an OP-TEE Trusted Application identified by
>>>>>> UUID 80a4c275-0a47-4905-8285-1486a9771a08.
>>>>>>
>>>>>> The TEE service node is a child of the "linaro,optee-tz" firmware 
>>>>>> node and
>>>>>> acts as a container for remoteproc devices that are controlled via 
>>>>>> TEE.
>>>>>
>>>>> Is this generic for any remoteproc device or just ST's remoteproc. 
>>>>> Looks
>>>>> like the latter to me.
>>>>
>>>> That's true, the DT description of the remoteproc subnode is very
>>>> specific to the vendor which in this case is ST.
>>>>
>>>>>
>>>>>> In addition, the "linaro,optee-tz" binding is updated to specify the
>>>>>> '#address-cells' and '#size-cells' values used for child TEE service
>>>>>> nodes.
>>>>>
>>>>> I'm pretty sure I already rejected per service/app child nodes for
>>>>> OP-TEE when its binding was submitted.
>>>>
>>>> That was the reason to have discoverable TEE bus in first place and I
>>>> have been motivating people to dynamically discover firmware properties
>>>> rather than hardcoding in the DT.
>>>>
>>>>> If we do need something in DT
>>>>> to define some resources, then can't we have some sort of
>>>>> standard/common communications channel? I don't care to see some 
>>>>> sort of
>>>>> free-for-all where we have every vendor doing their own thing. OP-TEE
>>>>> needs to standarize this.
>>>>
>>>> I suppose this requires a wider scope work as you can see the DT 
>>>> resource
>>>> dependence from here [1]. By standardize communication channel, do you
>>>> mean to say if adding an alternative backend to fwnode for TEE in
>>>> parallel to DT, ACPI or swnode is the way to go for discovering fw
>>>> properties?
>>>
>>> No, not at all.
>>>
>>>> Or do you have any other suggestion here?
>>>
>>> What I mean is why doesn't the TEE define the communication channel
>>> (mailbox+shmem and notification interrupt) rather than each TEE app?
>>
>> The synchronous communication channel is already there for each TEE app
>> based on (invoke commands + TEE shared memory). OP-TEE does support
>> notification interrupts too but those haven't been exposed to TEE client
>> drivers yet. I suppose this remoteproc use-case can be a good example to
>> expose that as a generic TEE notification interface too.
> 
> In the STM32MP series, the mailboxes and shared RAM are used for RPMsg 
> communication between Linux and the remote processor. My concern is that 
> using notification in OP-TEE could impact performance by introducing 
> latency. Additionally, this might require a DMA allocator in OP-TEE to 
> manage the shared memory. One RPMsg virtio requires the declaration of 
> at least three carveouts. Managing these as memory regions in OP-TEE 
> would be complex (due to limited number of memory area declaration on 
> STM32MP2).
>>
>>>
>>> More generally, is having TEE apps depending on random DT resources
>>> really a box we want to open? Is the next thing going to be a TEE
>>> clock/reset/gpio/power provider? Where do we draw the line?
>>
>> This is really a hard line to draw since silicon/OEM vendors based on 
>> their
>> hardware security architecture partition various resources among TEE and
>> the Linux world. And one general principle we try to follow for the TEE
>> is to keep it's Trusted Computing Base (TCB) to a minimal too.
>>
>> IMHO, if the threat model is well understood then we should allow for
>> this hetrogenous partitioning of system resources.
> 
> Here are some additional resources we need to manage the remote 
> processor, which seem complex to handle without Device Tree (DT):
> 
> - Clocks: On STM32MP, we manage clocks through the OP-TEE SCMI service
>    [1]. The SCMI OP-TEE clock/reset service already exists and should be
>    reused.
> - Power domains
> - Remoteproc Watchdog interrupt: Cannot be caught by OP-TEE on
>    stm32mp15.
> - Graceful shutdown of the remote processor: This involves sending a
>    mailbox notification to request shutdown and waiting up to 500 ms for
>    the remoteproc to deinitialize its resources. Waiting this long in the
>    secure context seems inefficient.
> - compatibility with some coming IPC mechanisms: Such as rpmsg_I2C or
>    virtio-msg might require remoteproc subnode descriptions in the
>    future.
> 
> If the proposed topology does not gain consensus, what about an 
> alternative approach that manages the remoteproc TEE similarly to SCMI, 
> by introducing a remoteproc-backend with the proc ID as a parameter?
> 
> 
> &firmware {
>      optee: optee {
>          compatible = "linaro,optee-tz";
>          method = "smc";
>          sproc: sproc {
>              compatible = "80a4c275-0a47-4905-8285-1486a9771a08";
>              #address-cells = <1>;
>          #size-cells = <0>;
>          };
>      };
> };
> 
> rproc1: m33@0 {
>    [...]
> 
>    remoteproc-backend = < &sproc 0>
> };
> 
> 
> rproc2: m0@0 {
>    [...]
> 
>    remoteproc-backend = < &sproc 1>
> };
> 
> 
> [1]https://elixir.bootlin.com/linux/v6.18.4/source/drivers/clk/clk-scmi.c
> 
> Thanks,
> Arnaud
> 
>>
>> -Sumit
> 
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32