Re: [PATCH 1/2] dt-bindings: arm: arm,scmi: add smc/hvc transports
From: Sudeep Holla <hidden>
Date: 2020-02-07 11:32:40
Also in:
linux-devicetree, lkml
On Fri, Feb 07, 2020 at 11:09:48AM +0000, Marc Zyngier wrote:
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.txtb/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 shallbe 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 ? Just use SMC or HVC conduit from PSCI/SMCCC. I don't think you need anything more than the function ID. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel