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? 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? Rob
