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 [off-list ref] wrote:

quoted

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

+++++++++++++++++++++

quoted

 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

quoted

+eng.fan%40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d
3bc2b4c

quoted

+6fa92cd99c5c301635%7C0%7C1%7C637027415448196145&sdata=xd
nUObNqlRF

quoted

+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%

quoted

+40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d3bc2b4c6
fa92cd9

quoted

+9c5c301635%7C0%7C1%7C637027415448196145&sdata=wl%2Fdg09
QMS%2FoHgI

quoted

+yD7ZBNpoIGXYxfFDRWhyYHogFd6A%3D&reserved=0
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+  - Peng Fan [off-list ref]
+
+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

quoted

+ 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.

quoted

+  Upon receiving an SMC using one of the described SMC function
+ identifiers,  the firmware is expected to trigger some mailbox connected

functionality.

quoted

+  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.

quoted

+
+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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel