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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+_S8UY7s7WQg9jXuBXCYMBWVCy=kVDMdkKTx6RctqQJA@mail.gmail.com>
Date: Fri, 2 Jan 2026 16:17:27 -0600
From: Rob Herring <robh@...nel.org>
To: Sumit Garg <sumit.garg@...nel.org>
Cc: Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>, Bjorn Andersson <andersson@...nel.org>, 
	Mathieu Poirier <mathieu.poirier@...aro.org>, Jens Wiklander <jens.wiklander@...aro.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-stm32@...md-mailman.stormreply.com, 
	linux-arm-kernel@...ts.infradead.org, linux-remoteproc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, op-tee@...ts.trustedfirmware.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH v20 1/6] dt-bindings: firmware: Add TEE remoteproc service binding

On Tue, Dec 30, 2025 at 5:10 AM Sumit Garg <sumit.garg@...nel.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