> Subject: Re: [PATCH 1/2] dt-bindings: arm: arm,scmi: add smc/hvc transports > > On Fri, Feb 07, 2020 at 10:08:36AM +0000, Marc Zyngier wrote: > > On 2020-02-06 13:01, peng.fan@xxxxxxx wrote: > > > From: Peng Fan <peng.fan@xxxxxxx> > > > > > > SCMI could use SMC/HVC as tranports, so add into devicetree binding > > > doc. > > > > > > Signed-off-by: Peng Fan <peng.fan@xxxxxxx> > > > --- > > > 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") > > > 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. The multiple protocols might use SMC or HVC. Saying Protocol@x { method="smc"; arm,func-id=<0x....> }; Protocol@y { method="hvc"; arm,func-id=<0x....> }; With my propose: Protocol@x { arm,smc-id=<0x....> }; Protocol@y { arm,hvc-id=<0x....> }; No need an extra method property to indicate it is smc or hvc. The driver use take arm,smc-id as SMC, arm,hvc-id as HVC. Thanks, Peng. > > > Other SMC/HVC capable protocols are able to pick the right one based > > on the PSCI conduit. > > > > This make it clear, but I am asking to be sure. > > > This is how the Spectre mitigations work already. Why is that any different? > > > > I don't see any need for it to be different. > > -- > Regards, > Sudeep