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. Best regards, Krzysztof
