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

Rob Herring
2026-01-02T22:17:40Z

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?

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