Hi sorry, I sent the mail while i was still typing it... Here is with the full answer. On Tue, 1 Mar 2022 at 15:05, Etienne Carriere <etienne.carriere@xxxxxxxxxx> wrote: > > Hello Ahmad, > > On Mon, 28 Feb 2022 at 17:01, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > > > Hello Etienne, > > > > On 28.10.21 16:00, Etienne Carriere wrote: > > > Introduce compatible "linaro,scmi-optee" for SCMI transport channel > > > based on an OP-TEE service invocation. The compatible mandates a > > > channel ID defined with property "linaro,optee-channel-id". > > > > I just found this thread via the compatible in the STM32MP131 patch set: > > https://lore.kernel.org/all/20220225133137.813919-1-gabriel.fernandez@xxxxxxxxxxx/ > > > > Linux doesn't care whether PSCI is provided by TF-A, OP-TEE or something > > else, so there is just the arm,psci* compatible. > > > > What's different about SCMI that this is not possible? Why couldn't the > > existing binding and driver be used to communicate with OP-TEE as secure > > monitor as well? > > Compatible "linaro,scmi-optee" denote a alternate SCMI transport to > those already in v5.16. It is names scmi-optee because the interface exposed to access SCMI services is based on TEE's interface (UUID to open a session with and invoke commands). The compatible is described in the Linux Documentation but not yet merged in the linux-next. It can be found in the tree of arm_scmi driver maintainers: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-linux-next This commit: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/commit/?h=for-linux-next&id=b7d2cf7c817b86e705b97f72c6be192a6760a14f Br, Etienne > > > > > > Cheers, > > Ahmad > > > > > > > > Cc: devicetree@xxxxxxxxxxxxxxx > > > Cc: Rob Herring <robh+dt@xxxxxxxxxx> > > > Signed-off-by: Etienne Carriere <etienne.carriere@xxxxxxxxxx> > > > --- > > > Changes since v6: > > > - Remove maxItems from linaro,optee-channel-id description > > > > > > No change since v5 > > > > > > Changes since v4: > > > - Fix sram node name in DTS example: s/-shm-/-sram-/ > > > > > > Changes since v3: > > > - Add description for linaro,optee-channel-id in patternProperties > > > specifying protocol can optionaly define a dedicated channel id. > > > - Fix DTS example (duplicated phandles issue, subnodes ordering) > > > - Fix typo in DTS example and description comments. > > > > > > Changes since v2: > > > - Define mandatory property linaro,optee-channel-id > > > - Rebased on yaml description file > > > > > > Changes since v1: > > > - Removed modification regarding mboxes property description. > > > --- > > > .../bindings/firmware/arm,scmi.yaml | 65 +++++++++++++++++++ > > > 1 file changed, 65 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > index 5c4c6782e052..eae15df36eef 100644 > > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > > @@ -38,6 +38,9 @@ properties: > > > The virtio transport only supports a single device. > > > items: > > > - const: arm,scmi-virtio > > > + - description: SCMI compliant firmware with OP-TEE transport > > > + items: > > > + - const: linaro,scmi-optee > > > > > > interrupts: > > > description: > > > @@ -83,6 +86,11 @@ properties: > > > description: > > > SMC id required when using smc or hvc transports > > > > > > + linaro,optee-channel-id: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: > > > + Channel specifier required when using OP-TEE transport. > > > + > > > protocol@11: > > > type: object > > > properties: > > > @@ -195,6 +203,12 @@ patternProperties: > > > minItems: 1 > > > maxItems: 2 > > > > > > + linaro,optee-channel-id: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: > > > + Channel specifier required when using OP-TEE transport and > > > + protocol has a dedicated communication channel. > > > + > > > required: > > > - reg > > > > > > @@ -226,6 +240,16 @@ else: > > > - arm,smc-id > > > - shmem > > > > > > + else: > > > + if: > > > + properties: > > > + compatible: > > > + contains: > > > + const: linaro,scmi-optee > > > + then: > > > + required: > > > + - linaro,optee-channel-id > > > + > > > examples: > > > - | > > > firmware { > > > @@ -340,7 +364,48 @@ examples: > > > reg = <0x11>; > > > #power-domain-cells = <1>; > > > }; > > > + }; > > > + }; > > > + > > > + - | > > > + firmware { > > > + scmi { > > > + compatible = "linaro,scmi-optee"; > > > + linaro,optee-channel-id = <0>; > > > + > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + scmi_dvfs1: protocol@13 { > > > + reg = <0x13>; > > > + linaro,optee-channel-id = <1>; > > > + shmem = <&cpu_optee_lpri0>; > > > + #clock-cells = <1>; > > > + }; > > > + > > > + scmi_clk0: protocol@14 { > > > + reg = <0x14>; > > > + #clock-cells = <1>; > > > + }; > > > + }; > > > + }; > > > > > > + soc { > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + > > > + sram@51000000 { > > > + compatible = "mmio-sram"; > > > + reg = <0x0 0x51000000 0x0 0x10000>; > > > + > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + ranges = <0 0x0 0x51000000 0x10000>; > > > + > > > + cpu_optee_lpri0: optee-sram-section@0 { > > > + compatible = "arm,scmi-shmem"; > > > + reg = <0x0 0x80>; > > > + }; > > > }; > > > }; > > > > > > > > > -- > > Pengutronix e.K. | | > > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
