Subject: Re: [PATCH 1/2] dt-bindings: arm: arm,scmi: add smc/hvc transports

On Fri, Feb 07, 2020 at 11:09:48AM +0000, Marc Zyngier wrote:

quoted

On 2020-02-07 11:00, Peng Fan wrote:

quoted

quoted

Subject: Re: [PATCH 1/2] dt-bindings: arm: arm,scmi: add smc/hvc
transports

On 2020-02-07 10:47, Sudeep Holla wrote:

quoted

On Fri, Feb 07, 2020 at 10:08:36AM +0000, Marc Zyngier wrote:

quoted

On 2020-02-06 13:01, peng.fan@nxp.com wrote:

quoted

From: Peng Fan <peng.fan@nxp.com>

SCMI could use SMC/HVC as tranports, so add into devicetree
binding doc.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Documentation/devicetree/bindings/arm/arm,scmi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git
a/Documentation/devicetree/bindings/arm/arm,scmi.txt
b/Documentation/devicetree/bindings/arm/arm,scmi.txt
index f493d69e6194..03cff8b55a93 100644

--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt

@@ -14,7 +14,7 @@ Required properties:

 The scmi node with the following properties shall be under

the /firmware/ node.

-- compatible : shall be "arm,scmi"
+- compatible : shall be "arm,scmi" or "arm,scmi-smc"
 - mboxes: List of phandle and mailbox channel specifiers. It
should contain
 	  exactly one or two mailboxes, one for transmitting

messages("tx")

quoted

quoted

quoted

quoted

quoted

quoted

 	  and another optional for receiving the
notifications("rx") if @@ -25,6 +25,8 @@ The scmi node with
the following properties shall be under the /firmware/ node.
 	  protocol identifier for a given sub-node.
 - #size-cells : should be '0' as 'reg' property doesn't have any size
 	  associated with it.
+- arm,smc-id : SMC id required when using smc transports
+- arm,hvc-id : HVC id required when using hvc transports

 Optional properties:

Not directly related to DT: Why do we need to distinguish
between SMC and HVC?

IIUC you want just one property to get the function ID ? Does
that align with what you are saying ? I wanted to ask the same
question and I see no need for 2 different properties.

Exactly. Using SMC or HVC should come from the context, and there
is zero value in having different different IDs, depending on the
conduit.

We *really* want SMC and HVC to behave the same way. Any attempt
to make them different should just be NAKed.

ok. Then just like psci node,
Add a "method" property for each protocol, and add "arm,func-id" to
indicate the ID.

How about this?

Or rather just a function ID, full stop. the conduit *MUST* be
inherited from the PSCI context.

Absolutely, this is what I was expecting.

Peng,

You have already introduced a compatible for smc/hvc transport instead of
default mailbox, why do you need anything more ? 

No.

Just use SMC or HVC

conduit from PSCI/SMCCC. I don't think you need anything more than the
function ID.

Yes, only function ID for now. If function ID could not be standardized in short
term, I could first mark smc-id optional in dt bindings, then smc transports
driver will first parse smc-id, abort if not exist. When ARM has standarlized
ID, we could switch to use that ID if smc-id not exist.

Thanks,
Peng.

--
Regards,
Sudeep

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