On 3/19/26 11:41, Krzysztof Kozlowski wrote:
On 19/03/2026 11:31, Arnaud POULIQUEN wrote:
Hello Krzysztof,
On 3/19/26 09:06, Krzysztof Kozlowski wrote:
On Tue, Mar 17, 2026 at 07:03:23PM +0100, Arnaud Pouliquen wrote:
Add a Device Tree binding for the STM32 remote processor controlled
via a Trusted Application running in OP-TEE.
This binding describes the interface and properties required for STM32MP
remoteproc instances managed by the TEE rproc service, including a
linkage to the TEE backend through the property "rproc-tee-phandle".
Signed-off-by: Arnaud Pouliquen <[email protected]>
---
V21 updates:
- the m4 node is no more declared as a child of the optee-rproc node
- "rproc-tee-phandle" property is introduced to reference the optee-rproc
---
.../remoteproc/st,stm32-rproc-tee.yaml | 108 ++++++++++++++++++
1 file changed, 108 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
diff --git
a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
new file mode 100644
index 000000000000..ca4dd1c8e7b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/st,stm32-rproc-tee.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 remote processor controlled via TEE
+
+maintainers:
+ - Arnaud Pouliquen <[email protected]>
+
+description: |
+ STM32MP remote processor controlled by a Trusted Application
+ running in OP-TEE. This node is a child of the TEE remoteproc service
+ (UUID 80a4c275-0a47-4905-8285-1486a9771a08) and exposes a remoteproc
+ instance managed by the Linux remoteproc core via the TEE rproc service.
+
+ Firmware loading, authentication and remote processor start/stop are managed
+ by the TEE application. The STM32-specific driver handles platform resources
+ such as the mailboxes and reserved-memory.
+
+properties:
+ compatible:
+ const: st,stm32mp1-m4-tee
Drop "tee", it suggests that compatible is tied to implementation of FW
you put there.
The "st,stm32mp1-m4" compatible string already exists in
Then probably this binding needs changes, because in general you should
not have two compatibles for the same hardware. Maybe that's special
case, but then needs explanations in commit msg why is that.
drivers/remoteproc/stm32_rproc.c, and "st,stm32mp1-m4-tee" compatible is
upstreamed in OP-TEE.
That is not our problem and strong no-go. Other projects are supposed to
participate in upstream bindings review and take the bindings once they
are reviewed and accepted here. If they take without review, it's their
problem.
Imagine that: some whatever project takes whatever crap (not saying
Optee is like that, just imagine for sake of discussion) and then you
send bindings to upstream and claim "that project took it, so you must
do as well". Great loophole to squeeze poor stuff to the kernel, so any
such argument is for me a warning sign.
Notice that I have also the stm32mp2 SoC to upstream expecting to have
similar compatible:
- st,stm32mp1-m33
- st,stm32mp2-m33-tee
Depending on the compatible string, the hardware behavior changes.
With the "xxxx-tee" compatible, OP-TEE also manages the isolation of
remote processor resources (memory, clock reset, peripherals).
Without the "xxxx-tee" compatible, OP-TEE have to ensure that the Linux
has the good access right to manage the remote processor.
Still the same device, no?
You can have a property defining how Linux should access such device,
e.g. because FW does this and that.
For instance if st,stm32mp1-m4-tee is set instead of st,stm32mp1-m4, on
linux side
- only memory regions used for IPC should be declared
- memory regions containing the remote firmware must not be declared as
not accessible by the Linux ( managed by OP-TEE).
- resets must not be declared ( managed by OP-TEE)
You probably don't remember, as it was a long time ago, but we already
discussed this point with Rob[1].
[1] https://lkml.org/lkml/2024/1/18/100
Do it still reasonable to you and Rob or should we find an alternative?
Get ack from Rob then.
A previous acknowledgment from Rob was given here:
https://lkml.org/lkml/2024/2/22/1264.
What frustrates me is that, if the compatible usage is no longer
accepted, I have lost time basing all my other versions on this
assumption. But that’s part of the game, and this series is already a
concatenation of redesigns resulting in version V21.
My expectation is simply that you and Rob provide me with a clear
direction to move forward.
The compatible string is one topic; I also need an acknowledgment or
rejection of the concept of using a phandle to link the remoteproc
driver with the TEE service.
Thanks and regards,
Arnaud
Best regards,
Krzysztof
