| Message ID | 1567004515-3567-2-git-send-email-peng.fan@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mailbox: arm: introduce smc triggered mailbox | expand |
On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote: > From: Peng Fan <peng.fan@nxp.com> > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction set, not as a standard endorsed by ARM Ltd. > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++ > 1 file changed, 125 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > new file mode 100644 > index 000000000000..f8eb28d5e307 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM SMC Mailbox Interface > + > +maintainers: > + - Peng Fan <peng.fan@nxp.com> > + > +description: | > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > + call) instruction to trigger a mailbox-connected activity in firmware, > + executing on the very same core as the caller. By nature this operation > + is synchronous and this mailbox provides no way for asynchronous messages > + to be delivered the other way round, from firmware to the OS, but > + asynchronous notification could also be supported. What do you mean by that ? I would prefer to drop the above line unless I am missing something. IMO it contradicts the previous statement less you elaborate more on this. > However the value of > + r0/w0/x0 the firmware returns after the smc call is delivered as a received > + message to the mailbox framework, so a synchronous communication can be > + established, for a asynchronous notification, no value will be returned. I assume you refer to asynchronous communication from OS to firmware in the above statement and "not asynchronous notification" from firmware to OS. > + The exact meaning of both the action the mailbox triggers as well as the > + return value is defined by their users and is not subject to this binding. > + > + One use case of this mailbox is the SCMI interface, which uses shared memory > + to transfer commands and parameters, and a mailbox to trigger a function > + call. This allows SoCs without a separate management processor (or when > + such a processor is not available or used) to use this standardized > + interface anyway. > + Not sure if reference to SCMI is needed at all but I don't have any objections to it, just thought worth mentioning. > + This binding describes no hardware, but establishes a firmware interface. > + Upon receiving an SMC using one of the described SMC function identifiers, > + the firmware is expected to trigger some mailbox connected functionality. > + The communication follows the ARM SMC calling convention. > + Firmware expects an SMC function identifier in r0 or w0. The supported > + identifiers are passed from consumers, or listed in the the arm,func-ids > + properties as described below. The firmware can return one value in > + the first SMC result register, it is expected to be an error value, > + which shall be propagated to the mailbox client. > + > + Any core which supports the SMC or HVC instruction can be used, as long as > + a firmware component running in EL3 or EL2 is handling these calls. > + Other than the above points, I am fine with it. Once fixed, Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Note I haven't reviewed the yaml scheme, but just binding in general. -- Regards, Sudeep
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 > +++++++++++++++++++++ > > 1 file changed, 125 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index 000000000000..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C637025974936865698&sdata=Inp > %2FLs39m > > +Gv1fe3dZMSaGmgmyWPT6awPh47s3mEtQ%2BQ%3D&reserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1d3bc2b4c > 6fa92cd9 > > > +9c5c301635%7C0%7C1%7C637025974936865698&sdata=jmoR1Qqm7 > 6N5NwDbgFE > > +Fm8cpdW%2B%2FgqmG9mSGz9mXv58%3D&reserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan <peng.fan@nxp.com> > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > > > + asynchronous notification could also be supported. > > What do you mean by that ? I would prefer to drop the above line unless I am Ok. Dropped it in v6. > missing something. IMO it contradicts the previous statement less you > elaborate more on this. > > > However the value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > + received message to the mailbox framework, so a synchronous > > + communication can be established, for a asynchronous notification, no > value will be returned. > > I assume you refer to asynchronous communication from OS to firmware in > the above statement and "not asynchronous notification" from firmware to > OS. Since asynchronous notification dropped, so it should only be synchronous communication could be established. So I'll modify it as below: r0/w0/x0 the firmware returns after the smc call is delivered as a received message to the mailbox framework, so synchronous communication can be established > > > + The exact meaning of both the action the mailbox triggers as well > > + as the return value is defined by their users and is not subject to this > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > Not sure if reference to SCMI is needed at all but I don't have any objections > to it, just thought worth mentioning. > > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > > Other than the above points, I am fine with it. Once fixed, > > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Thanks, Peng. > > Note I haven't reviewed the yaml scheme, but just binding in general. > > -- > Regards, > Sudeep
On Tue, Aug 27, 2019 at 10:02 PM Peng Fan <peng.fan@nxp.com> wrote: > > From: Peng Fan <peng.fan@nxp.com> > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction set, not as a standard endorsed by ARM Ltd. > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++ > 1 file changed, 125 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > new file mode 100644 > index 000000000000..f8eb28d5e307 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM SMC Mailbox Interface > + > +maintainers: > + - Peng Fan <peng.fan@nxp.com> > + > +description: | > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > + call) instruction to trigger a mailbox-connected activity in firmware, > + executing on the very same core as the caller. By nature this operation > + is synchronous and this mailbox provides no way for asynchronous messages > + to be delivered the other way round, from firmware to the OS, but > + asynchronous notification could also be supported. However the value of > + r0/w0/x0 the firmware returns after the smc call is delivered as a received > + message to the mailbox framework, so a synchronous communication can be > + established, for a asynchronous notification, no value will be returned. > + The exact meaning of both the action the mailbox triggers as well as the > + return value is defined by their users and is not subject to this binding. > + > + One use case of this mailbox is the SCMI interface, which uses shared memory > + to transfer commands and parameters, and a mailbox to trigger a function > + call. This allows SoCs without a separate management processor (or when > + such a processor is not available or used) to use this standardized > + interface anyway. > + > + This binding describes no hardware, but establishes a firmware interface. > + Upon receiving an SMC using one of the described SMC function identifiers, > + the firmware is expected to trigger some mailbox connected functionality. > + The communication follows the ARM SMC calling convention. > + Firmware expects an SMC function identifier in r0 or w0. The supported > + identifiers are passed from consumers, or listed in the the arm,func-ids > + properties as described below. The firmware can return one value in > + the first SMC result register, it is expected to be an error value, > + which shall be propagated to the mailbox client. > + > + Any core which supports the SMC or HVC instruction can be used, as long as > + a firmware component running in EL3 or EL2 is handling these calls. > + > +properties: > + compatible: > + const: arm,smc-mbox > + > + "#mbox-cells": > + const: 1 > + > + arm,num-chans: > + description: The number of channels supported. > + items: > + minimum: 1 > + maximum: 4096 # Should be enough? > + > + method: > + - enum: > + - smc > + - hvc > + > + transports: > + - enum: > + - mem > + - reg > + > + arm,func-ids: > + description: | > + An array of 32-bit values specifying the function IDs used by each > + mailbox channel. Those function IDs follow the ARM SMC calling > + convention standard [1]. > + > + There is one identifier per channel and the number of supported > + channels is determined by the length of this array. > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 0 > + maxItems: 4096 # Should be enough? > + > +required: > + - compatible > + - "#mbox-cells" > + - arm,num-chans > + - transports > + - method > + > +examples: > + - | > + sram@910000 { > + compatible = "mmio-sram"; > + reg = <0x0 0x93f000 0x0 0x1000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x0 0x93f000 0x1000>; > + > + cpu_scp_lpri: scp-shmem@0 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x200>; > + }; > + > + cpu_scp_hpri: scp-shmem@200 { > + compatible = "arm,scmi-shmem"; > + reg = <0x200 0x200>; > + }; > + }; > + > + firmware { > + smc_mbox: mailbox { > + #mbox-cells = <1>; > + compatible = "arm,smc-mbox"; > + method = "smc"; > + arm,num-chans = <0x2>; > + transports = "mem"; > + /* Optional */ > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > SMC/HVC is synchronously(block) running in "secure mode", i.e, there can only be one instance running platform wide. Right? That implies there is only one physical channel in the platform. So if you need to initiate different functions (tx, rx), you call them sequentially by changing the func-id for each request. Why not? -Jassi
Hi Jassi, > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Tue, Aug 27, 2019 at 10:02 PM Peng Fan <peng.fan@nxp.com> wrote: > > > > From: Peng Fan <peng.fan@nxp.com> > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 > +++++++++++++++++++++ > > 1 file changed, 125 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index 000000000000..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d > 3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C637027415448196145&sdata=xd > nUObNqlRF > > +lu8NiXSuc35fYrHIzR%2Fyak6IzW05Q3nA%3D&reserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d3bc2b4c6 > fa92cd9 > > > +9c5c301635%7C0%7C1%7C637027415448196145&sdata=wl%2Fdg09 > QMS%2FoHgI > > +yD7ZBNpoIGXYxfFDRWhyYHogFd6A%3D&reserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan <peng.fan@nxp.com> > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the > > +value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > +received > > + message to the mailbox framework, so a synchronous communication > > +can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well > > +as the > > + return value is defined by their users and is not subject to this binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > +properties: > > + compatible: > > + const: arm,smc-mbox > > + > > + "#mbox-cells": > > + const: 1 > > + > > + arm,num-chans: > > + description: The number of channels supported. > > + items: > > + minimum: 1 > > + maximum: 4096 # Should be enough? > > + > > + method: > > + - enum: > > + - smc > > + - hvc > > + > > + transports: > > + - enum: > > + - mem > > + - reg > > + > > + arm,func-ids: > > + description: | > > + An array of 32-bit values specifying the function IDs used by each > > + mailbox channel. Those function IDs follow the ARM SMC calling > > + convention standard [1]. > > + > > + There is one identifier per channel and the number of supported > > + channels is determined by the length of this array. > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + minItems: 0 > > + maxItems: 4096 # Should be enough? > > + > > +required: > > + - compatible > > + - "#mbox-cells" > > + - arm,num-chans > > + - transports > > + - method > > + > > +examples: > > + - | > > + sram@910000 { > > + compatible = "mmio-sram"; > > + reg = <0x0 0x93f000 0x0 0x1000>; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges = <0 0x0 0x93f000 0x1000>; > > + > > + cpu_scp_lpri: scp-shmem@0 { > > + compatible = "arm,scmi-shmem"; > > + reg = <0x0 0x200>; > > + }; > > + > > + cpu_scp_hpri: scp-shmem@200 { > > + compatible = "arm,scmi-shmem"; > > + reg = <0x200 0x200>; > > + }; > > + }; > > + > > + firmware { > > + smc_mbox: mailbox { > > + #mbox-cells = <1>; > > + compatible = "arm,smc-mbox"; > > + method = "smc"; > > + arm,num-chans = <0x2>; > > + transports = "mem"; > > + /* Optional */ > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, there can > only be one instance running platform wide. Right? I think there could be channel for TEE, and channel for Linux. For virtualization case, there could be dedicated channel for each VM. That implies there is only > one physical channel in the platform. I don't think so, TEE/Linux should use different physical channels, i.e, SRAM memory partitioned using TZASC. So if you need to initiate different > functions (tx, rx), you call them sequentially by changing the func-id for each > request. Why not? I could not follow you clearly. Could you please share more details? Thanks, Peng. > > -Jassi
On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > +examples: > > > + - | > > > + sram@910000 { > > > + compatible = "mmio-sram"; > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > + > > > + cpu_scp_lpri: scp-shmem@0 { > > > + compatible = "arm,scmi-shmem"; > > > + reg = <0x0 0x200>; > > > + }; > > > + > > > + cpu_scp_hpri: scp-shmem@200 { > > > + compatible = "arm,scmi-shmem"; > > > + reg = <0x200 0x200>; > > > + }; > > > + }; > > > + > > > + firmware { > > > + smc_mbox: mailbox { > > > + #mbox-cells = <1>; > > > + compatible = "arm,smc-mbox"; > > > + method = "smc"; > > > + arm,num-chans = <0x2>; > > > + transports = "mem"; > > > + /* Optional */ > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, there can > > only be one instance running platform wide. Right? > > I think there could be channel for TEE, and channel for Linux. > For virtualization case, there could be dedicated channel for each VM. > I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be active at the same time, right?
Hi Jassi, > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > +examples: > > > > + - | > > > > + sram@910000 { > > > > + compatible = "mmio-sram"; > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > + #address-cells = <1>; > > > > + #size-cells = <1>; > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > + > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > + compatible = "arm,scmi-shmem"; > > > > + reg = <0x0 0x200>; > > > > + }; > > > > + > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > + compatible = "arm,scmi-shmem"; > > > > + reg = <0x200 0x200>; > > > > + }; > > > > + }; > > > > + > > > > + firmware { > > > > + smc_mbox: mailbox { > > > > + #mbox-cells = <1>; > > > > + compatible = "arm,smc-mbox"; > > > > + method = "smc"; > > > > + arm,num-chans = <0x2>; > > > > + transports = "mem"; > > > > + /* Optional */ > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, there > > > can only be one instance running platform wide. Right? > > > > I think there could be channel for TEE, and channel for Linux. > > For virtualization case, there could be dedicated channel for each VM. > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be > active at the same time, right? If I get your point correctly, On UP, both could not be active. On SMP, tx/rx could be both active, anyway this depends on secure firmware and Linux firmware design. Do you have any suggestions about arm,func-ids here? Thanks, Peng.
On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > Hi Jassi, > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > > SMC/HVC mailbox > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > +examples: > > > > > + - | > > > > > + sram@910000 { > > > > > + compatible = "mmio-sram"; > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > + #address-cells = <1>; > > > > > + #size-cells = <1>; > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > + > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > + compatible = "arm,scmi-shmem"; > > > > > + reg = <0x0 0x200>; > > > > > + }; > > > > > + > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > + compatible = "arm,scmi-shmem"; > > > > > + reg = <0x200 0x200>; > > > > > + }; > > > > > + }; > > > > > + > > > > > + firmware { > > > > > + smc_mbox: mailbox { > > > > > + #mbox-cells = <1>; > > > > > + compatible = "arm,smc-mbox"; > > > > > + method = "smc"; > > > > > + arm,num-chans = <0x2>; > > > > > + transports = "mem"; > > > > > + /* Optional */ > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, there > > > > can only be one instance running platform wide. Right? > > > > > > I think there could be channel for TEE, and channel for Linux. > > > For virtualization case, there could be dedicated channel for each VM. > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be > > active at the same time, right? > > If I get your point correctly, > On UP, both could not be active. On SMP, tx/rx could be both active, anyway > this depends on secure firmware and Linux firmware design. > > Do you have any suggestions about arm,func-ids here? > I was thinking if this is just an instruction, why can't each channel be represented as a controller, i.e, have exactly one func-id per controller node. Define as many controllers as you need channels ? -j
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > Hi Jassi, > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > for the ARM SMC/HVC mailbox > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > +examples: > > > > > > + - | > > > > > > + sram@910000 { > > > > > > + compatible = "mmio-sram"; > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > + #address-cells = <1>; > > > > > > + #size-cells = <1>; > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > + > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > + reg = <0x0 0x200>; > > > > > > + }; > > > > > > + > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > + reg = <0x200 0x200>; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + firmware { > > > > > > + smc_mbox: mailbox { > > > > > > + #mbox-cells = <1>; > > > > > > + compatible = "arm,smc-mbox"; > > > > > > + method = "smc"; > > > > > > + arm,num-chans = <0x2>; > > > > > > + transports = "mem"; > > > > > > + /* Optional */ > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, > > > > > there can only be one instance running platform wide. Right? > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > both be active at the same time, right? > > > > If I get your point correctly, > > On UP, both could not be active. On SMP, tx/rx could be both active, > > anyway this depends on secure firmware and Linux firmware design. > > > > Do you have any suggestions about arm,func-ids here? > > > I was thinking if this is just an instruction, why can't each channel be > represented as a controller, i.e, have exactly one func-id per controller node. > Define as many controllers as you need channels ? I am ok, this could make driver code simpler. Something as below? smc_tx_mbox: tx_mbox { #mbox-cells = <0>; compatible = "arm,smc-mbox"; method = "smc"; transports = "mem"; arm,func-id = <0xc20000fe>; }; smc_rx_mbox: rx_mbox { #mbox-cells = <0>; compatible = "arm,smc-mbox"; method = "smc"; transports = "mem"; arm,func-id = <0xc20000ff>; }; firmware { scmi { compatible = "arm,scmi"; mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; mbox-names = "tx", "rx"; shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; }; }; Thanks, Peng. > > -j
On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote: > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > > SMC/HVC mailbox > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > Hi Jassi, > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > > for the ARM SMC/HVC mailbox > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > > +examples: > > > > > > > + - | > > > > > > > + sram@910000 { > > > > > > > + compatible = "mmio-sram"; > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > + #address-cells = <1>; > > > > > > > + #size-cells = <1>; > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > + > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > + reg = <0x0 0x200>; > > > > > > > + }; > > > > > > > + > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > + reg = <0x200 0x200>; > > > > > > > + }; > > > > > > > + }; > > > > > > > + > > > > > > > + firmware { > > > > > > > + smc_mbox: mailbox { > > > > > > > + #mbox-cells = <1>; > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > + method = "smc"; > > > > > > > + arm,num-chans = <0x2>; > > > > > > > + transports = "mem"; > > > > > > > + /* Optional */ > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, > > > > > > there can only be one instance running platform wide. Right? > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > > both be active at the same time, right? > > > > > > If I get your point correctly, > > > On UP, both could not be active. On SMP, tx/rx could be both active, > > > anyway this depends on secure firmware and Linux firmware design. > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > I was thinking if this is just an instruction, why can't each channel be > > represented as a controller, i.e, have exactly one func-id per controller node. > > Define as many controllers as you need channels ? > > I am ok, this could make driver code simpler. Something as below? > > smc_tx_mbox: tx_mbox { > #mbox-cells = <0>; > compatible = "arm,smc-mbox"; > method = "smc"; > transports = "mem"; > arm,func-id = <0xc20000fe>; > }; > > smc_rx_mbox: rx_mbox { > #mbox-cells = <0>; > compatible = "arm,smc-mbox"; > method = "smc"; > transports = "mem"; > arm,func-id = <0xc20000ff>; > }; > > firmware { > scmi { > compatible = "arm,scmi"; > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > mbox-names = "tx", "rx"; > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > }; > }; > Yes, the channel part is good. But I am not convinced by the need to have SCMI specific "transport" mode. thanks
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > for the ARM SMC/HVC mailbox > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > Hi Jassi, > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding > > > > > doc for the ARM SMC/HVC mailbox > > > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > > > > +examples: > > > > > > > > + - | > > > > > > > > + sram@910000 { > > > > > > > > + compatible = "mmio-sram"; > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > > + #address-cells = <1>; > > > > > > > > + #size-cells = <1>; > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > > + > > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > + reg = <0x0 0x200>; > > > > > > > > + }; > > > > > > > > + > > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > + reg = <0x200 0x200>; > > > > > > > > + }; > > > > > > > > + }; > > > > > > > > + > > > > > > > > + firmware { > > > > > > > > + smc_mbox: mailbox { > > > > > > > > + #mbox-cells = <1>; > > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > > + method = "smc"; > > > > > > > > + arm,num-chans = <0x2>; > > > > > > > > + transports = "mem"; > > > > > > > > + /* Optional */ > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", > > > > > > > i.e, there can only be one instance running platform wide. Right? > > > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > > For virtualization case, there could be dedicated channel for each > VM. > > > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, > > > > > can't both be active at the same time, right? > > > > > > > > If I get your point correctly, > > > > On UP, both could not be active. On SMP, tx/rx could be both > > > > active, anyway this depends on secure firmware and Linux firmware > design. > > > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > > > I was thinking if this is just an instruction, why can't each > > > channel be represented as a controller, i.e, have exactly one func-id per > controller node. > > > Define as many controllers as you need channels ? > > > > I am ok, this could make driver code simpler. Something as below? > > > > smc_tx_mbox: tx_mbox { > > #mbox-cells = <0>; > > compatible = "arm,smc-mbox"; > > method = "smc"; > > transports = "mem"; > > arm,func-id = <0xc20000fe>; > > }; > > > > smc_rx_mbox: rx_mbox { > > #mbox-cells = <0>; > > compatible = "arm,smc-mbox"; > > method = "smc"; > > transports = "mem"; > > arm,func-id = <0xc20000ff>; > > } > > > > firmware { > > scmi { > > compatible = "arm,scmi"; > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > > mbox-names = "tx", "rx"; > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > > }; > > }; > > > Yes, the channel part is good. > But I am not convinced by the need to have SCMI specific "transport" mode. SCMI spec only support shared memory message. However to make this driver generic, need to take care of message using ARM registers. If using shared memory message, the call will be invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0, 0, 0); If using ARM registers to transfer message, the call will be invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3, cmd->a4, cmd->a5, cmd->a6, cmd->a7); So I added "transports" mode. Code as below: if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) { if (chan_data->function_id != UINT_MAX) function_id = chan_data->function_id; else function_id = cmd->a0; chan_id = chan_data->chan_id; ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0, 0, 0); } else { ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3, cmd->a4, cmd->a5, cmd->a6, cmd->a7); } Per Sudeep's comments in previous version, better pass chan_id to secure firmware. If drop the "transports" mode, I do not have a good idea how to differentiate the two cases, reg and mem. Any suggestions? Thanks, Peng. > > thanks
On Fri, Aug 30, 2019 at 07:37:41AM +0000, Peng Fan wrote: > Hi Jassi, > > > I think there could be channel for TEE, and channel for Linux. > > > For virtualization case, there could be dedicated channel for each VM. > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be > > active at the same time, right? > > If I get your point correctly, > On UP, both could not be active. On SMP, tx/rx could be both active, anyway > this depends on secure firmware and Linux firmware design. > Just to confirm, we can't have SMC/HVC based Rx channel as there's no *architectural* way to achieve it. So it can be based on some interrupt from secure side and hence will be a *different* type of channel/controller. Sorry to make this point repeatedly, but juts to be absolutely clear: as it stands, SMC/HVC can be used only for Tx today. -- Regards, Sudeep
On Fri, Aug 30, 2019 at 02:52:40AM -0500, Jassi Brar wrote: > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: [...] > > > > If I get your point correctly, > > On UP, both could not be active. On SMP, tx/rx could be both active, anyway > > this depends on secure firmware and Linux firmware design. > > > > Do you have any suggestions about arm,func-ids here? > > > I was thinking if this is just an instruction, why can't each channel > be represented as a controller, i.e, have exactly one func-id per > controller node. Define as many controllers as you need channels ? > I might have missed to follow this, but what's the advantage of doing so ? Which can't single controller instance deal with all the channels ? -- Regards, Sudeep
Hi Sudeep > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Fri, Aug 30, 2019 at 07:37:41AM +0000, Peng Fan wrote: > > Hi Jassi, > > > > I think there could be channel for TEE, and channel for Linux. > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > both be active at the same time, right? > > > > If I get your point correctly, > > On UP, both could not be active. On SMP, tx/rx could be both active, > > anyway this depends on secure firmware and Linux firmware design. > > > > Just to confirm, we can't have SMC/HVC based Rx channel as there's no > *architectural* way to achieve it. So it can be based on some interrupt from > secure side and hence will be a *different* type of channel/controller. > > Sorry to make this point repeatedly, but juts to be absolutely clear: > as it stands, SMC/HVC can be used only for Tx today. Since interrupt notification was dropped in v5, I need to drop RX description in v6. Thanks, Peng. > > -- > Regards, > Sudeep
On Fri, Aug 30, 2019 at 4:32 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Fri, Aug 30, 2019 at 02:52:40AM -0500, Jassi Brar wrote: > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > [...] > > > > > > > If I get your point correctly, > > > On UP, both could not be active. On SMP, tx/rx could be both active, anyway > > > this depends on secure firmware and Linux firmware design. > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > I was thinking if this is just an instruction, why can't each channel > > be represented as a controller, i.e, have exactly one func-id per > > controller node. Define as many controllers as you need channels ? > > > > I might have missed to follow this, but what's the advantage of doing so ? > Which can't single controller instance deal with all the channels ? > There are many advantages ... 1) Design reflects the reality - two smc/hvc instructions have nothing tying them together. 2) Driver code becomes simpler - don't have to pre-populate channels, deducting from the size of func-ids array. 3) Driver becomes more flexible - We can have channels that pass func-id runtime and channels that pass via DT (if we must have the option of DT property). -jassi
On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote: > From: Peng Fan <peng.fan@nxp.com> > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction set, not as a standard endorsed by ARM Ltd. > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++ > 1 file changed, 125 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > new file mode 100644 > index 000000000000..f8eb28d5e307 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM SMC Mailbox Interface > + > +maintainers: > + - Peng Fan <peng.fan@nxp.com> > + > +description: | > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > + call) instruction to trigger a mailbox-connected activity in firmware, > + executing on the very same core as the caller. By nature this operation > + is synchronous and this mailbox provides no way for asynchronous messages > + to be delivered the other way round, from firmware to the OS, but > + asynchronous notification could also be supported. However the value of > + r0/w0/x0 the firmware returns after the smc call is delivered as a received > + message to the mailbox framework, so a synchronous communication can be > + established, for a asynchronous notification, no value will be returned. > + The exact meaning of both the action the mailbox triggers as well as the > + return value is defined by their users and is not subject to this binding. > + > + One use case of this mailbox is the SCMI interface, which uses shared memory > + to transfer commands and parameters, and a mailbox to trigger a function > + call. This allows SoCs without a separate management processor (or when > + such a processor is not available or used) to use this standardized > + interface anyway. > + > + This binding describes no hardware, but establishes a firmware interface. > + Upon receiving an SMC using one of the described SMC function identifiers, > + the firmware is expected to trigger some mailbox connected functionality. > + The communication follows the ARM SMC calling convention. > + Firmware expects an SMC function identifier in r0 or w0. The supported > + identifiers are passed from consumers, or listed in the the arm,func-ids > + properties as described below. The firmware can return one value in > + the first SMC result register, it is expected to be an error value, > + which shall be propagated to the mailbox client. > + > + Any core which supports the SMC or HVC instruction can be used, as long as > + a firmware component running in EL3 or EL2 is handling these calls. > + > +properties: > + compatible: > + const: arm,smc-mbox > + > + "#mbox-cells": > + const: 1 > + > + arm,num-chans: > + description: The number of channels supported. > + items: > + minimum: 1 > + maximum: 4096 # Should be enough? > + > + method: > + - enum: Did you build this with 'make dt_binding_check' as this should be a warning. This should not be a list entry (i.e. drop the '-'). > + - smc > + - hvc > + > + transports: arm,transports > + - enum: > + - mem > + - reg > + > + arm,func-ids: > + description: | > + An array of 32-bit values specifying the function IDs used by each > + mailbox channel. Those function IDs follow the ARM SMC calling > + convention standard [1]. > + > + There is one identifier per channel and the number of supported > + channels is determined by the length of this array. > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 0 > + maxItems: 4096 # Should be enough? > + > +required: > + - compatible > + - "#mbox-cells" > + - arm,num-chans > + - transports > + - method > + > +examples: > + - | > + sram@910000 { > + compatible = "mmio-sram"; > + reg = <0x0 0x93f000 0x0 0x1000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x0 0x93f000 0x1000>; > + > + cpu_scp_lpri: scp-shmem@0 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x200>; > + }; > + > + cpu_scp_hpri: scp-shmem@200 { > + compatible = "arm,scmi-shmem"; > + reg = <0x200 0x200>; > + }; > + }; > + > + firmware { > + smc_mbox: mailbox { > + #mbox-cells = <1>; > + compatible = "arm,smc-mbox"; > + method = "smc"; > + arm,num-chans = <0x2>; > + transports = "mem"; > + /* Optional */ > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > + }; > + > + scmi { > + compatible = "arm,scmi"; > + mboxes = <&smc_mbox 0>, <&smc_mbox 1>; > + mbox-names = "tx", "rx"; > + shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > + }; > + }; > + > +... > -- > 2.16.4 >
On Mon, Sep 2, 2019 at 2:39 PM Rob Herring <robh@kernel.org> wrote: > > On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > > actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++ > > 1 file changed, 125 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index 000000000000..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan <peng.fan@nxp.com> > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > > + call) instruction to trigger a mailbox-connected activity in firmware, > > + executing on the very same core as the caller. By nature this operation > > + is synchronous and this mailbox provides no way for asynchronous messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a received > > + message to the mailbox framework, so a synchronous communication can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well as the > > + return value is defined by their users and is not subject to this binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses shared memory > > + to transfer commands and parameters, and a mailbox to trigger a function > > + call. This allows SoCs without a separate management processor (or when > > + such a processor is not available or used) to use this standardized > > + interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware interface. > > + Upon receiving an SMC using one of the described SMC function identifiers, > > + the firmware is expected to trigger some mailbox connected functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The supported > > + identifiers are passed from consumers, or listed in the the arm,func-ids > > + properties as described below. The firmware can return one value in > > + the first SMC result register, it is expected to be an error value, > > + which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as long as > > + a firmware component running in EL3 or EL2 is handling these calls. > > + > > +properties: > > + compatible: > > + const: arm,smc-mbox > > + > > + "#mbox-cells": > > + const: 1 > > + > > + arm,num-chans: > > + description: The number of channels supported. > > + items: > > + minimum: 1 > > + maximum: 4096 # Should be enough? > > + > > + method: > > + - enum: > > Did you build this with 'make dt_binding_check' as this should be a > warning. This should not be a list entry (i.e. drop the '-'). > > > + - smc > > + - hvc > > + > > + transports: > > arm,transports > > > + - enum: > > + - mem > > + - reg > > + > > + arm,func-ids: > > + description: | > > + An array of 32-bit values specifying the function IDs used by each > > + mailbox channel. Those function IDs follow the ARM SMC calling > > + convention standard [1]. > > + > > + There is one identifier per channel and the number of supported > > + channels is determined by the length of this array. > > + $ref: /schemas/types.yaml#/definitions/uint32-array Also, this doesn't work. You need: allOf: - $ref: /schemas/types.yaml#/definitions/uint32-array > > + minItems: 0 > > + maxItems: 4096 # Should be enough?
On Fri, 30 Aug 2019 03:12:29 -0500 Jassi Brar <jassisinghbrar@gmail.com> wrote: Hi, > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > > > SMC/HVC mailbox > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > Hi Jassi, > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > > > for the ARM SMC/HVC mailbox > > > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > > > > +examples: > > > > > > > > + - | > > > > > > > > + sram@910000 { > > > > > > > > + compatible = "mmio-sram"; > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > > + #address-cells = <1>; > > > > > > > > + #size-cells = <1>; > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > > + > > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > + reg = <0x0 0x200>; > > > > > > > > + }; > > > > > > > > + > > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > + reg = <0x200 0x200>; > > > > > > > > + }; > > > > > > > > + }; > > > > > > > > + > > > > > > > > + firmware { > > > > > > > > + smc_mbox: mailbox { > > > > > > > > + #mbox-cells = <1>; > > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > > + method = "smc"; > > > > > > > > + arm,num-chans = <0x2>; > > > > > > > > + transports = "mem"; > > > > > > > > + /* Optional */ > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, > > > > > > > there can only be one instance running platform wide. Right? > > > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > > > both be active at the same time, right? > > > > > > > > If I get your point correctly, > > > > On UP, both could not be active. On SMP, tx/rx could be both active, > > > > anyway this depends on secure firmware and Linux firmware design. > > > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > > > I was thinking if this is just an instruction, why can't each channel be > > > represented as a controller, i.e, have exactly one func-id per controller node. > > > Define as many controllers as you need channels ? > > > > I am ok, this could make driver code simpler. Something as below? > > > > smc_tx_mbox: tx_mbox { > > #mbox-cells = <0>; > > compatible = "arm,smc-mbox"; > > method = "smc"; > > transports = "mem"; > > arm,func-id = <0xc20000fe>; > > }; > > > > smc_rx_mbox: rx_mbox { > > #mbox-cells = <0>; > > compatible = "arm,smc-mbox"; > > method = "smc"; > > transports = "mem"; > > arm,func-id = <0xc20000ff>; > > }; > > > > firmware { > > scmi { > > compatible = "arm,scmi"; > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > > mbox-names = "tx", "rx"; > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > > }; > > }; > > > Yes, the channel part is good. > But I am not convinced by the need to have SCMI specific "transport" mode. Why would this be SCMI specific and what is the problem with having this property? By the very nature of the SMC/HVC call you would expect to also pass parameters in registers. However this limits the amount of data you can push, so the option of reverting to a memory based payload sounds very reasonable. On the other hand *just* using memory complicates things, in case you have a very simple protocol. You would need a memory region shared between firmware and OS, which is not always easily possible on every platform. Also this doesn't scale easily with multiple mailboxes and channels. Passing parameters via registers is also naturally consistent, as there would be no races and no need for synchronisation with other cores or other users of the mailbox. So I clearly see the benefit of specifying *both* ways of payload transport. Given that this driver should be protocol agnostic, it makes a lot of sense to introduce both methods *now*, so in the future users can just use the register method, without extending the binding in a incompatible way later (earlier kernels would have the driver, but wouldn't know how to deal with this parameter). Cheers, Andre.
On Wed, 28 Aug 2019 03:02:58 +0000 Peng Fan <peng.fan@nxp.com> wrote: Hi, sorry for the late reply, eventually managed to have a closer look on this. > From: Peng Fan <peng.fan@nxp.com> > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction set, not as a standard endorsed by ARM Ltd. > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++ > 1 file changed, 125 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > new file mode 100644 > index 000000000000..f8eb28d5e307 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ARM SMC Mailbox Interface > + > +maintainers: > + - Peng Fan <peng.fan@nxp.com> > + > +description: | > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > + call) instruction to trigger a mailbox-connected activity in firmware, > + executing on the very same core as the caller. By nature this operation > + is synchronous and this mailbox provides no way for asynchronous messages > + to be delivered the other way round, from firmware to the OS, but > + asynchronous notification could also be supported. However the value of > + r0/w0/x0 the firmware returns after the smc call is delivered as a received > + message to the mailbox framework, so a synchronous communication can be > + established, for a asynchronous notification, no value will be returned. > + The exact meaning of both the action the mailbox triggers as well as the > + return value is defined by their users and is not subject to this binding. > + > + One use case of this mailbox is the SCMI interface, which uses shared memory > + to transfer commands and parameters, and a mailbox to trigger a function > + call. This allows SoCs without a separate management processor (or when > + such a processor is not available or used) to use this standardized > + interface anyway. > + > + This binding describes no hardware, but establishes a firmware interface. > + Upon receiving an SMC using one of the described SMC function identifiers, > + the firmware is expected to trigger some mailbox connected functionality. > + The communication follows the ARM SMC calling convention. > + Firmware expects an SMC function identifier in r0 or w0. The supported > + identifiers are passed from consumers, or listed in the the arm,func-ids > + properties as described below. The firmware can return one value in > + the first SMC result register, it is expected to be an error value, > + which shall be propagated to the mailbox client. > + > + Any core which supports the SMC or HVC instruction can be used, as long as > + a firmware component running in EL3 or EL2 is handling these calls. > + > +properties: > + compatible: > + const: arm,smc-mbox > + > + "#mbox-cells": > + const: 1 > + > + arm,num-chans: > + description: The number of channels supported. > + items: > + minimum: 1 > + maximum: 4096 # Should be enough? This maximum sounds rather arbitrary. Why do we need one? In the driver this just allocates more memory, so why not just impose no artificial limit at all? Actually, do we need this property at all? Can't we just rely on the size of arm,func-ids to determine this (using of_property_count_elems_of_size() in the driver)? Having both sounds redundant and brings up the question what to do if they don't match. > + > + method: > + - enum: > + - smc > + - hvc > + > + transports: > + - enum: > + - mem > + - reg Shouldn't there be a description on what both mean, exactly? For instance I would expect a list of registers to be shown for the "reg" case, and be it by referring to the ARM SMCCC. Also looking at the driver this brings up more questions: - Which memory does mem refer to? If this is really the means of transport, it should be referenced in this *controller* node and populated by the driver. Looking at the example below and the driver code, it actually isn't used that way, instead the memory is used and controlled by the mailbox *client*. - What is the actual difference between the two transports? For "mem" we just populate the registers with 0, for "reg" we use the data. Couldn't this be left to the client? There are more points which makes me think this property is actually redundant, see my comments on patch 2/2. > + > + arm,func-ids: > + description: | > + An array of 32-bit values specifying the function IDs used by each > + mailbox channel. Those function IDs follow the ARM SMC calling > + convention standard [1]. > + > + There is one identifier per channel and the number of supported > + channels is determined by the length of this array. I think this makes it obvious that arm,num-chans is not needed. Also this somewhat contradicts the driver implementation, which allows the array to be shorter, marking this as UINT_MAX and later on using the first data item as a function identifier. This is somewhat surprising and not documented (unless I missed something). So I would suggest: - We drop the transports property, and always put the client provided data in the registers, according to the SMCCC. Document this here. A client not needing those could always puts zeros (or garbage) in there, the respective firmware would just ignore the registers. - We drop "arm,num-chans", as this is just redundant with the length of the func-ids array. - We don't impose an arbitrary limit on the number of channels. From the firmware point of view this is just different function IDs, from Linux' point of view just the size of the memory used. Both don't need to be limited artificially IMHO. - We mark arm,func-ids as required, as this needs to be fixed, allocated number. For the question of "always one channel per controller" vs. "allow multiple channels per controller": I don't really have a strong opinion, but lean towards allowing multiple channels. This would allow to group functions belonging together, separating them from totally distinct controller uses (think virtual GPIO vs. SCMI). And it would still allow the special case of multiple single-channel controllers to be naturally specified. > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 0 > + maxItems: 4096 # Should be enough? > + > +required: > + - compatible > + - "#mbox-cells" > + - arm,num-chans > + - transports > + - method According to the above description arm,func-ids would also be required? Cheers, Andre. > + > +examples: > + - | > + sram@910000 { > + compatible = "mmio-sram"; > + reg = <0x0 0x93f000 0x0 0x1000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x0 0x93f000 0x1000>; > + > + cpu_scp_lpri: scp-shmem@0 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x200>; > + }; > + > + cpu_scp_hpri: scp-shmem@200 { > + compatible = "arm,scmi-shmem"; > + reg = <0x200 0x200>; > + }; > + }; > + > + firmware { > + smc_mbox: mailbox { > + #mbox-cells = <1>; > + compatible = "arm,smc-mbox"; > + method = "smc"; > + arm,num-chans = <0x2>; > + transports = "mem"; > + /* Optional */ > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > + }; > + > + scmi { > + compatible = "arm,scmi"; > + mboxes = <&smc_mbox 0>, <&smc_mbox 1>; > + mbox-names = "tx", "rx"; > + shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > + }; > + }; > + > +...
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Fri, 30 Aug 2019 03:12:29 -0500 > Jassi Brar <jassisinghbrar@gmail.com> wrote: > > Hi, > > > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > > for the ARM SMC/HVC mailbox > > > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > Hi Jassi, > > > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding > > > > > > doc for the ARM SMC/HVC mailbox > > > > > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> > wrote: > > > > > > > > > > > > > > > +examples: > > > > > > > > > + - | > > > > > > > > > + sram@910000 { > > > > > > > > > + compatible = "mmio-sram"; > > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > > > + #address-cells = <1>; > > > > > > > > > + #size-cells = <1>; > > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > > > + > > > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > + reg = <0x0 0x200>; > > > > > > > > > + }; > > > > > > > > > + > > > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > + reg = <0x200 0x200>; > > > > > > > > > + }; > > > > > > > > > + }; > > > > > > > > > + > > > > > > > > > + firmware { > > > > > > > > > + smc_mbox: mailbox { > > > > > > > > > + #mbox-cells = <1>; > > > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > > > + method = "smc"; > > > > > > > > > + arm,num-chans = <0x2>; > > > > > > > > > + transports = "mem"; > > > > > > > > > + /* Optional */ > > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", > > > > > > > > i.e, there can only be one instance running platform wide. Right? > > > > > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > > > For virtualization case, there could be dedicated channel for each > VM. > > > > > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, > > > > > > can't both be active at the same time, right? > > > > > > > > > > If I get your point correctly, > > > > > On UP, both could not be active. On SMP, tx/rx could be both > > > > > active, anyway this depends on secure firmware and Linux firmware > design. > > > > > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > > > > > I was thinking if this is just an instruction, why can't each > > > > channel be represented as a controller, i.e, have exactly one func-id per > controller node. > > > > Define as many controllers as you need channels ? > > > > > > I am ok, this could make driver code simpler. Something as below? > > > > > > smc_tx_mbox: tx_mbox { > > > #mbox-cells = <0>; > > > compatible = "arm,smc-mbox"; > > > method = "smc"; > > > transports = "mem"; > > > arm,func-id = <0xc20000fe>; > > > }; > > > > > > smc_rx_mbox: rx_mbox { > > > #mbox-cells = <0>; > > > compatible = "arm,smc-mbox"; > > > method = "smc"; > > > transports = "mem"; > > > arm,func-id = <0xc20000ff>; > > > }; > > > > > > firmware { > > > scmi { > > > compatible = "arm,scmi"; > > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > > > mbox-names = "tx", "rx"; > > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > > > }; > > > }; > > > > > Yes, the channel part is good. > > But I am not convinced by the need to have SCMI specific "transport" mode. > > Why would this be SCMI specific and what is the problem with having this > property? > By the very nature of the SMC/HVC call you would expect to also pass > parameters in registers. However this limits the amount of data you can push, > so the option of reverting to a memory based payload sounds very > reasonable. > On the other hand *just* using memory complicates things, in case you have a > very simple protocol. You would need a memory region shared between > firmware and OS, which is not always easily possible on every platform. Also > this doesn't scale easily with multiple mailboxes and channels. Passing > parameters via registers is also naturally consistent, as there would be no > races and no need for synchronisation with other cores or other users of the > mailbox. > > So I clearly see the benefit of specifying *both* ways of payload transport. > Given that this driver should be protocol agnostic, it makes a lot of sense to > introduce both methods *now*, so in the future users can just use the register > method, without extending the binding in a incompatible way later (earlier > kernels would have the driver, but wouldn't know how to deal with this > parameter). Andre, thanks for your explanation. Jassi, are you ok that this property "transport" is kept in V6? Thanks, Peng. > > Cheers, > Andre.
On Mon, Sep 9, 2019 at 8:32 AM Andre Przywara <andre.przywara@arm.com> wrote: > > On Fri, 30 Aug 2019 03:12:29 -0500 > Jassi Brar <jassisinghbrar@gmail.com> wrote: > > Hi, > > > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > > > > SMC/HVC mailbox > > > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > Hi Jassi, > > > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > > > > for the ARM SMC/HVC mailbox > > > > > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > > > > > > +examples: > > > > > > > > > + - | > > > > > > > > > + sram@910000 { > > > > > > > > > + compatible = "mmio-sram"; > > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > > > + #address-cells = <1>; > > > > > > > > > + #size-cells = <1>; > > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > > > + > > > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > + reg = <0x0 0x200>; > > > > > > > > > + }; > > > > > > > > > + > > > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > + reg = <0x200 0x200>; > > > > > > > > > + }; > > > > > > > > > + }; > > > > > > > > > + > > > > > > > > > + firmware { > > > > > > > > > + smc_mbox: mailbox { > > > > > > > > > + #mbox-cells = <1>; > > > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > > > + method = "smc"; > > > > > > > > > + arm,num-chans = <0x2>; > > > > > > > > > + transports = "mem"; > > > > > > > > > + /* Optional */ > > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, > > > > > > > > there can only be one instance running platform wide. Right? > > > > > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > > > > both be active at the same time, right? > > > > > > > > > > If I get your point correctly, > > > > > On UP, both could not be active. On SMP, tx/rx could be both active, > > > > > anyway this depends on secure firmware and Linux firmware design. > > > > > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > > > > > I was thinking if this is just an instruction, why can't each channel be > > > > represented as a controller, i.e, have exactly one func-id per controller node. > > > > Define as many controllers as you need channels ? > > > > > > I am ok, this could make driver code simpler. Something as below? > > > > > > smc_tx_mbox: tx_mbox { > > > #mbox-cells = <0>; > > > compatible = "arm,smc-mbox"; > > > method = "smc"; > > > transports = "mem"; > > > arm,func-id = <0xc20000fe>; > > > }; > > > > > > smc_rx_mbox: rx_mbox { > > > #mbox-cells = <0>; > > > compatible = "arm,smc-mbox"; > > > method = "smc"; > > > transports = "mem"; > > > arm,func-id = <0xc20000ff>; > > > }; > > > > > > firmware { > > > scmi { > > > compatible = "arm,scmi"; > > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > > > mbox-names = "tx", "rx"; > > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > > > }; > > > }; > > > > > Yes, the channel part is good. > > But I am not convinced by the need to have SCMI specific "transport" mode. > > Why would this be SCMI specific and what is the problem with having this property? > By the very nature of the SMC/HVC call you would expect to also pass parameters in registers. > However this limits the amount of data you can push, so the option of reverting to a > memory based payload sounds very reasonable. > Of course, it is very legit to pass data via mem and many platforms do that. But as you note in your next post, the 'transport' doesn't seem necessary doing what it does in the driver. Cheers!
On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara <andre.przywara@arm.com> wrote: > > On Wed, 28 Aug 2019 03:02:58 +0000 > Peng Fan <peng.fan@nxp.com> wrote: > > Hi, > > sorry for the late reply, eventually managed to have a closer look on this. > > > From: Peng Fan <peng.fan@nxp.com> > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > > actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++ > > 1 file changed, 125 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index 000000000000..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan <peng.fan@nxp.com> > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > > + call) instruction to trigger a mailbox-connected activity in firmware, > > + executing on the very same core as the caller. By nature this operation > > + is synchronous and this mailbox provides no way for asynchronous messages > > + to be delivered the other way round, from firmware to the OS, but > > + asynchronous notification could also be supported. However the value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a received > > + message to the mailbox framework, so a synchronous communication can be > > + established, for a asynchronous notification, no value will be returned. > > + The exact meaning of both the action the mailbox triggers as well as the > > + return value is defined by their users and is not subject to this binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses shared memory > > + to transfer commands and parameters, and a mailbox to trigger a function > > + call. This allows SoCs without a separate management processor (or when > > + such a processor is not available or used) to use this standardized > > + interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware interface. > > + Upon receiving an SMC using one of the described SMC function identifiers, > > + the firmware is expected to trigger some mailbox connected functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The supported > > + identifiers are passed from consumers, or listed in the the arm,func-ids > > + properties as described below. The firmware can return one value in > > + the first SMC result register, it is expected to be an error value, > > + which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as long as > > + a firmware component running in EL3 or EL2 is handling these calls. > > + > > +properties: > > + compatible: > > + const: arm,smc-mbox > > + > > + "#mbox-cells": > > + const: 1 > > + > > + arm,num-chans: > > + description: The number of channels supported. > > + items: > > + minimum: 1 > > + maximum: 4096 # Should be enough? > > This maximum sounds rather arbitrary. Why do we need one? In the driver this just allocates more memory, so why not just impose no artificial limit at all? > This will be gone, once the driver is converted to 1channel per controller. > Actually, do we need this property at all? Can't we just rely on the size of arm,func-ids to determine this (using of_property_count_elems_of_size() in the driver)? Having both sounds redundant and brings up the question what to do if they don't match. > > > + > > + method: > > + - enum: > > + - smc > > + - hvc > > + > > + transports: > > + - enum: > > + - mem > > + - reg > > Shouldn't there be a description on what both mean, exactly? > For instance I would expect a list of registers to be shown for the "reg" case, and be it by referring to the ARM SMCCC. > > Also looking at the driver this brings up more questions: > - Which memory does mem refer to? If this is really the means of transport, it should be referenced in this *controller* node and populated by the driver. Looking at the example below and the driver code, it actually isn't used that way, instead the memory is used and controlled by the mailbox *client*. > - What is the actual difference between the two transports? For "mem" we just populate the registers with 0, for "reg" we use the data. Couldn't this be left to the client? > > There are more points which makes me think this property is actually redundant, see my comments on patch 2/2. > > > + > > + arm,func-ids: > > + description: | > > + An array of 32-bit values specifying the function IDs used by each > > + mailbox channel. Those function IDs follow the ARM SMC calling > > + convention standard [1]. > > + > > + There is one identifier per channel and the number of supported > > + channels is determined by the length of this array. > > I think this makes it obvious that arm,num-chans is not needed. > > Also this somewhat contradicts the driver implementation, which allows the array to be shorter, marking this as UINT_MAX and later on using the first data item as a function identifier. This is somewhat surprising and not documented (unless I missed something). > > So I would suggest: > - We drop the transports property, and always put the client provided data in the registers, according to the SMCCC. Document this here. > A client not needing those could always puts zeros (or garbage) in there, the respective firmware would just ignore the registers. > - We drop "arm,num-chans", as this is just redundant with the length of the func-ids array. > - We don't impose an arbitrary limit on the number of channels. From the firmware point of view this is just different function IDs, from Linux' point of view just the size of the memory used. Both don't need to be limited artificially IMHO. > Sounds like we are in sync. > - We mark arm,func-ids as required, as this needs to be fixed, allocated number. > I still think func-id can be done without. A client can always pass the value as it knows what it expects. But I can live with it being optional. cheers!
On Tue, 10 Sep 2019 21:36:35 -0500 Jassi Brar <jassisinghbrar@gmail.com> wrote: Hi, > On Mon, Sep 9, 2019 at 8:32 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > On Fri, 30 Aug 2019 03:12:29 -0500 > > Jassi Brar <jassisinghbrar@gmail.com> wrote: > > > > Hi, > > > > > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > > > > > SMC/HVC mailbox > > > > > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > > > Hi Jassi, > > > > > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > > > > > for the ARM SMC/HVC mailbox > > > > > > > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote: > > > > > > > > > > > > > > > > > +examples: > > > > > > > > > > + - | > > > > > > > > > > + sram@910000 { > > > > > > > > > > + compatible = "mmio-sram"; > > > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > > > > + #address-cells = <1>; > > > > > > > > > > + #size-cells = <1>; > > > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > > > > + > > > > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > > + reg = <0x0 0x200>; > > > > > > > > > > + }; > > > > > > > > > > + > > > > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > > + reg = <0x200 0x200>; > > > > > > > > > > + }; > > > > > > > > > > + }; > > > > > > > > > > + > > > > > > > > > > + firmware { > > > > > > > > > > + smc_mbox: mailbox { > > > > > > > > > > + #mbox-cells = <1>; > > > > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > > > > + method = "smc"; > > > > > > > > > > + arm,num-chans = <0x2>; > > > > > > > > > > + transports = "mem"; > > > > > > > > > > + /* Optional */ > > > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, > > > > > > > > > there can only be one instance running platform wide. Right? > > > > > > > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > > > > > both be active at the same time, right? > > > > > > > > > > > > If I get your point correctly, > > > > > > On UP, both could not be active. On SMP, tx/rx could be both active, > > > > > > anyway this depends on secure firmware and Linux firmware design. > > > > > > > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > > > > > > > I was thinking if this is just an instruction, why can't each channel be > > > > > represented as a controller, i.e, have exactly one func-id per controller node. > > > > > Define as many controllers as you need channels ? > > > > > > > > I am ok, this could make driver code simpler. Something as below? > > > > > > > > smc_tx_mbox: tx_mbox { > > > > #mbox-cells = <0>; > > > > compatible = "arm,smc-mbox"; > > > > method = "smc"; > > > > transports = "mem"; > > > > arm,func-id = <0xc20000fe>; > > > > }; > > > > > > > > smc_rx_mbox: rx_mbox { > > > > #mbox-cells = <0>; > > > > compatible = "arm,smc-mbox"; > > > > method = "smc"; > > > > transports = "mem"; > > > > arm,func-id = <0xc20000ff>; > > > > }; > > > > > > > > firmware { > > > > scmi { > > > > compatible = "arm,scmi"; > > > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > > > > mbox-names = "tx", "rx"; > > > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > > > > }; > > > > }; > > > > > > > Yes, the channel part is good. > > > But I am not convinced by the need to have SCMI specific "transport" mode. > > > > Why would this be SCMI specific and what is the problem with having this property? > > By the very nature of the SMC/HVC call you would expect to also pass parameters in registers. > > However this limits the amount of data you can push, so the option of reverting to a > > memory based payload sounds very reasonable. > > > Of course, it is very legit to pass data via mem and many platforms do > that. But as you note in your next post, the 'transport' doesn't seem > necessary doing what it does in the driver. Yes, indeed. I didn't realise that until looking more deeply into the driver later. So I think we are on the same page regarding this: the *controller* driver and its binding does not need to know about the transport, that's something between the mailbox client and the firmware implementation. Cheers, Andre.
On Tue, 10 Sep 2019 21:44:11 -0500 Jassi Brar <jassisinghbrar@gmail.com> wrote: Hi, > On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > On Wed, 28 Aug 2019 03:02:58 +0000 > > Peng Fan <peng.fan@nxp.com> wrote: > > [ ... ] > > > > > + > > > + arm,func-ids: > > > + description: | > > > + An array of 32-bit values specifying the function IDs used by each > > > + mailbox channel. Those function IDs follow the ARM SMC calling > > > + convention standard [1]. > > > + > > > + There is one identifier per channel and the number of supported > > > + channels is determined by the length of this array. > > > > I think this makes it obvious that arm,num-chans is not needed. > > > > Also this somewhat contradicts the driver implementation, which allows the array to be shorter, marking this as UINT_MAX and later on using the first data item as a function identifier. This is somewhat surprising and not documented (unless I missed something). > > > > So I would suggest: > > - We drop the transports property, and always put the client provided data in the registers, according to the SMCCC. Document this here. > > A client not needing those could always puts zeros (or garbage) in there, the respective firmware would just ignore the registers. > > - We drop "arm,num-chans", as this is just redundant with the length of the func-ids array. > > - We don't impose an arbitrary limit on the number of channels. From the firmware point of view this is just different function IDs, from Linux' point of view just the size of the memory used. Both don't need to be limited artificially IMHO. > > > Sounds like we are in sync. > > > - We mark arm,func-ids as required, as this needs to be fixed, allocated number. > > > I still think func-id can be done without. A client can always pass > the value as it knows what it expects. I don't think it's the right abstraction. The mailbox *controller* uses a specific func-id, this has to match the one the firmware expects. So this is a property of the mailbox transport channel (the SMC call), and the *client* should *not* care about it. It just sees the logical channel ID (if we have one), which the controller translates into the func-ID. So it should really look like this (assuming only single channel controllers): mailbox: smc-mailbox { #mbox-cells = <0>; compatible = "arm,smc-mbox"; method = "smc"; arm,func-id = <0x820000fe>; }; scmi { compatible = "arm,scmi"; mboxes = <&smc_mbox>; mbox-names = "tx"; /* rx is optional */ shmem = <&cpu_scp_hpri>; }; If you allow the client to provide the function ID (and I am not saying this is a good idea): where would this func ID come from? It would need to be a property of the client DT node, then. So one way would be to use the func ID as the Linux mailbox channel ID: mailbox: smc-mailbox { #mbox-cells = <1>; compatible = "arm,smc-mbox"; method = "smc"; }; scmi { compatible = "arm,scmi"; mboxes = <&smc_mbox 0x820000fe>; mbox-names = "tx"; /* rx is optional */ shmem = <&cpu_scp_hpri>; }; But this doesn't look desirable. And as I mentioned this before: allowing some mailbox clients to provide the function IDs sound scary, as they could use anything they want, triggering random firmware actions (think PSCI_CPU_OFF). So I think we should have a required "arm,func-id" property, with exactly one 32-bit value (again assuming single channel controllers). Cheers, Andre.
On Wed, Sep 11, 2019 at 10:03 AM Andre Przywara <andre.przywara@arm.com> wrote: > > On Tue, 10 Sep 2019 21:44:11 -0500 > Jassi Brar <jassisinghbrar@gmail.com> wrote: > > Hi, > > > On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > On Wed, 28 Aug 2019 03:02:58 +0000 > > > Peng Fan <peng.fan@nxp.com> wrote: > > > > [ ... ] > > > > > > > + > > > > + arm,func-ids: > > > > + description: | > > > > + An array of 32-bit values specifying the function IDs used by each > > > > + mailbox channel. Those function IDs follow the ARM SMC calling > > > > + convention standard [1]. > > > > + > > > > + There is one identifier per channel and the number of supported > > > > + channels is determined by the length of this array. > > > > > > I think this makes it obvious that arm,num-chans is not needed. > > > > > > Also this somewhat contradicts the driver implementation, which allows the array to be shorter, marking this as UINT_MAX and later on using the first data item as a function identifier. This is somewhat surprising and not documented (unless I missed something). > > > > > > So I would suggest: > > > - We drop the transports property, and always put the client provided data in the registers, according to the SMCCC. Document this here. > > > A client not needing those could always puts zeros (or garbage) in there, the respective firmware would just ignore the registers. > > > - We drop "arm,num-chans", as this is just redundant with the length of the func-ids array. > > > - We don't impose an arbitrary limit on the number of channels. From the firmware point of view this is just different function IDs, from Linux' point of view just the size of the memory used. Both don't need to be limited artificially IMHO. > > > > > Sounds like we are in sync. > > > > > - We mark arm,func-ids as required, as this needs to be fixed, allocated number. > > > > > I still think func-id can be done without. A client can always pass > > the value as it knows what it expects. > > I don't think it's the right abstraction. The mailbox *controller* uses a specific func-id, this has to match the one the firmware expects. So this is a property of the mailbox transport channel (the SMC call), and the *client* should *not* care about it. It just sees the logical channel ID (if we have one), which the controller translates into the func-ID. > arg0 is special only to the client/protocol, otherwise it is simply the first argument for the arm_smccc_smc *instruction* controller. arg[1,7] are already provided by the client, so it is only neater if arg0 is also taken from the client. But as I said, I am still ok if func-id is passed from dt and arg0 from client is ignored because we have one channel per controller design and we don't have to worry about number of channels there can be dedicated to specific functions. > So it should really look like this (assuming only single channel controllers): > mailbox: smc-mailbox { > #mbox-cells = <0>; > compatible = "arm,smc-mbox"; > method = "smc"; > Do we want to do away with 'method' property and use different 'compatible' properties instead? compatible = "arm,smc-mbox"; or compatible = "arm,hvc-mbox"; > arm,func-id = <0x820000fe>; > }; > scmi { > compatible = "arm,scmi"; > mboxes = <&smc_mbox>; > mbox-names = "tx"; /* rx is optional */ > shmem = <&cpu_scp_hpri>; > }; > > If you allow the client to provide the function ID (and I am not saying this is a good idea): where would this func ID come from? It would need to be a property of the client DT node, then. So one way would be to use the func ID as the Linux mailbox channel ID: > mailbox: smc-mailbox { > #mbox-cells = <1>; > compatible = "arm,smc-mbox"; > method = "smc"; > }; > scmi { > compatible = "arm,scmi"; > mboxes = <&smc_mbox 0x820000fe>; > mbox-names = "tx"; /* rx is optional */ > shmem = <&cpu_scp_hpri>; > }; > > But this doesn't look desirable. > > And as I mentioned this before: allowing some mailbox clients to provide the function IDs sound scary, as they could use anything they want, triggering random firmware actions (think PSCI_CPU_OFF). > That paranoia is unwarranted. We have to keep faith in kernel-space code doing the right thing. Either the illegitimate function request should be rejected by the firmware or client driver be called buggy.... just as we would call a block device driver buggy if it messed up the sector numbers in a write request. thnx.
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Wed, Sep 11, 2019 at 10:03 AM Andre Przywara > <andre.przywara@arm.com> wrote: > > > > On Tue, 10 Sep 2019 21:44:11 -0500 > > Jassi Brar <jassisinghbrar@gmail.com> wrote: > > > > Hi, > > > > > On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara > <andre.przywara@arm.com> wrote: > > > > > > > > On Wed, 28 Aug 2019 03:02:58 +0000 Peng Fan <peng.fan@nxp.com> > > > > wrote: > > > > > > [ ... ] > > > > > > > > > + > > > > > + arm,func-ids: > > > > > + description: | > > > > > + An array of 32-bit values specifying the function IDs used by > each > > > > > + mailbox channel. Those function IDs follow the ARM SMC > calling > > > > > + convention standard [1]. > > > > > + > > > > > + There is one identifier per channel and the number of > supported > > > > > + channels is determined by the length of this array. > > > > > > > > I think this makes it obvious that arm,num-chans is not needed. > > > > > > > > Also this somewhat contradicts the driver implementation, which allows > the array to be shorter, marking this as UINT_MAX and later on using the first > data item as a function identifier. This is somewhat surprising and not > documented (unless I missed something). > > > > > > > > So I would suggest: > > > > - We drop the transports property, and always put the client provided > data in the registers, according to the SMCCC. Document this here. > > > > A client not needing those could always puts zeros (or garbage) in > there, the respective firmware would just ignore the registers. > > > > - We drop "arm,num-chans", as this is just redundant with the length of > the func-ids array. > > > > - We don't impose an arbitrary limit on the number of channels. From > the firmware point of view this is just different function IDs, from Linux' point > of view just the size of the memory used. Both don't need to be limited > artificially IMHO. > > > > > > > Sounds like we are in sync. > > > > > > > - We mark arm,func-ids as required, as this needs to be fixed, allocated > number. > > > > > > > I still think func-id can be done without. A client can always pass > > > the value as it knows what it expects. > > > > I don't think it's the right abstraction. The mailbox *controller* uses a > specific func-id, this has to match the one the firmware expects. So this is a > property of the mailbox transport channel (the SMC call), and the *client* > should *not* care about it. It just sees the logical channel ID (if we have one), > which the controller translates into the func-ID. > > > arg0 is special only to the client/protocol, otherwise it is simply the first > argument for the arm_smccc_smc *instruction* controller. > arg[1,7] are already provided by the client, so it is only neater if > arg0 is also taken from the client. > > But as I said, I am still ok if func-id is passed from dt and arg0 from client is > ignored because we have one channel per controller design and we don't have > to worry about number of channels there can be dedicated to specific > functions. Ok, so I'll make it an optional property. > > > So it should really look like this (assuming only single channel controllers): > > mailbox: smc-mailbox { > > #mbox-cells = <0>; > > compatible = "arm,smc-mbox"; > > method = "smc"; > > > Do we want to do away with 'method' property and use different 'compatible' > properties instead? > compatible = "arm,smc-mbox"; or compatible = "arm,hvc-mbox"; I am ok, just need add data in driver to differentiate smc/hvc. Andre, are you ok? Thanks, Peng. > > > arm,func-id = <0x820000fe>; > > }; > > scmi { > > compatible = "arm,scmi"; > > mboxes = <&smc_mbox>; > > mbox-names = "tx"; /* rx is optional */ > > shmem = <&cpu_scp_hpri>; > > }; > > > > If you allow the client to provide the function ID (and I am not saying this is > a good idea): where would this func ID come from? It would need to be a > property of the client DT node, then. So one way would be to use the func ID > as the Linux mailbox channel ID: > > mailbox: smc-mailbox { > > #mbox-cells = <1>; > > compatible = "arm,smc-mbox"; > > method = "smc"; > > }; > > scmi { > > compatible = "arm,scmi"; > > mboxes = <&smc_mbox 0x820000fe>; > > mbox-names = "tx"; /* rx is optional */ > > shmem = <&cpu_scp_hpri>; > > }; > > > > But this doesn't look desirable. > > > > And as I mentioned this before: allowing some mailbox clients to provide > the function IDs sound scary, as they could use anything they want, triggering > random firmware actions (think PSCI_CPU_OFF). > > > That paranoia is unwarranted. We have to keep faith in kernel-space code > doing the right thing. > Either the illegitimate function request should be rejected by the firmware or > client driver be called buggy.... just as we would call a block device driver > buggy if it messed up the sector numbers in a write request. > > thnx.
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml new file mode 100644 index 000000000000..f8eb28d5e307 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml @@ -0,0 +1,125 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM SMC Mailbox Interface + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +description: | + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor + call) instruction to trigger a mailbox-connected activity in firmware, + executing on the very same core as the caller. By nature this operation + is synchronous and this mailbox provides no way for asynchronous messages + to be delivered the other way round, from firmware to the OS, but + asynchronous notification could also be supported. However the value of + r0/w0/x0 the firmware returns after the smc call is delivered as a received + message to the mailbox framework, so a synchronous communication can be + established, for a asynchronous notification, no value will be returned. + The exact meaning of both the action the mailbox triggers as well as the + return value is defined by their users and is not subject to this binding. + + One use case of this mailbox is the SCMI interface, which uses shared memory + to transfer commands and parameters, and a mailbox to trigger a function + call. This allows SoCs without a separate management processor (or when + such a processor is not available or used) to use this standardized + interface anyway. + + This binding describes no hardware, but establishes a firmware interface. + Upon receiving an SMC using one of the described SMC function identifiers, + the firmware is expected to trigger some mailbox connected functionality. + The communication follows the ARM SMC calling convention. + Firmware expects an SMC function identifier in r0 or w0. The supported + identifiers are passed from consumers, or listed in the the arm,func-ids + properties as described below. The firmware can return one value in + the first SMC result register, it is expected to be an error value, + which shall be propagated to the mailbox client. + + Any core which supports the SMC or HVC instruction can be used, as long as + a firmware component running in EL3 or EL2 is handling these calls. + +properties: + compatible: + const: arm,smc-mbox + + "#mbox-cells": + const: 1 + + arm,num-chans: + description: The number of channels supported. + items: + minimum: 1 + maximum: 4096 # Should be enough? + + method: + - enum: + - smc + - hvc + + transports: + - enum: + - mem + - reg + + arm,func-ids: + description: | + An array of 32-bit values specifying the function IDs used by each + mailbox channel. Those function IDs follow the ARM SMC calling + convention standard [1]. + + There is one identifier per channel and the number of supported + channels is determined by the length of this array. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 0 + maxItems: 4096 # Should be enough? + +required: + - compatible + - "#mbox-cells" + - arm,num-chans + - transports + - method + +examples: + - | + sram@910000 { + compatible = "mmio-sram"; + reg = <0x0 0x93f000 0x0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x93f000 0x1000>; + + cpu_scp_lpri: scp-shmem@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x200>; + }; + + cpu_scp_hpri: scp-shmem@200 { + compatible = "arm,scmi-shmem"; + reg = <0x200 0x200>; + }; + }; + + firmware { + smc_mbox: mailbox { + #mbox-cells = <1>; + compatible = "arm,smc-mbox"; + method = "smc"; + arm,num-chans = <0x2>; + transports = "mem"; + /* Optional */ + arm,func-ids = <0xc20000fe>, <0xc20000ff>; + }; + + scmi { + compatible = "arm,scmi"; + mboxes = <&smc_mbox 0>, <&smc_mbox 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; + }; + }; + +...