[Linux-stm32] [PATCH v20 1/6] dt-bindings: firmware: Add TEE remoteproc service binding
Arnaud POULIQUEN
arnaud.pouliquen at foss.st.com
Wed Feb 18 23:51:35 PST 2026
Hello Rob,
Could you provide your feedback on my device tree (DT) proposal below
before I begin implementation? Your input would be greatly appreciated.
Thanks and Regards,
Arnaud
On 2/10/26 07:13, Sumit Garg wrote:
> Hi Arnaud,
>
> On Tue, Feb 03, 2026 at 08:42:34AM +0100, Arnaud POULIQUEN wrote:
>>
>> 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 at 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 at 0 {
>>> [...]
>>>
>>> remoteproc-backend = < &sproc 0>
>>> };
>>>
>>>
>>> rproc2: m0 at 0 {
>>> [...]
>>>
>>> remoteproc-backend = < &sproc 1>
>>> };
>
> Using a phandle like this makes it a bit more cleaner but I would defer
> to Rob since he has the final say here.
>
> -Sumit
>
>>>
>>>
>>> [1]https://elixir.bootlin.com/linux/v6.18.4/source/drivers/clk/clk-scmi.c
>>>
>>> Thanks,
>>> Arnaud
>>>
>>>>
>>>> -Sumit
>>>
>>> _______________________________________________
>>> Linux-stm32 mailing list
>>> Linux-stm32 at st-md-mailman.stormreply.com
>>> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
>>
More information about the linux-arm-kernel
mailing list