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

[Sumit Garg <sumit.garg@kernel.org>]

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@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>
> > };

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@st-md-mailman.stormreply.com
> > https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
>