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