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 arnaud.pouliquen@foss.st.com
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 arnaud.pouliquen@foss.st.com
+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