linux-kernel - Re: [RFC PATCH 1/8] Documentation: add DT binding for ARM System Control and Management Interface(SCMI) protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 9 Jun 2017 16:50:21 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Rob Herring <robh@...nel.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Roy Franz <roy.franz@...ium.com>,
        Harb Abdulhamid <harba@...eaurora.org>,
        Nishanth Menon <nm@...com>, Arnd Bergmann <arnd@...db.de>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [RFC PATCH 1/8] Documentation: add DT binding for ARM System
 Control and Management Interface(SCMI) protocol



On 09/06/17 16:39, Rob Herring wrote:
> On Fri, Jun 9, 2017 at 9:47 AM, Sudeep Holla <sudeep.holla@....com> wrote:
>>
>>
>> On 09/06/17 15:16, Rob Herring wrote:
>>> On Wed, Jun 07, 2017 at 05:10:05PM +0100, Sudeep Holla wrote:
>>>> This patch adds devicetree binding for System Control and Management
>>>> Interface (SCMI) Message Protocol used between the Application Cores(AP)
>>>> and the System Control Processor(SCP). The MHU peripheral provides a
>>>> mechanism for inter-processor communication between SCP's M3 processor
>>>> and AP.
>>>>
>>>> SCP offers control and management of the core/cluster power states,
>>>> various power domain DVFS including the core/cluster, certain system
>>>> clocks configuration, thermal sensors and many others.
>>>>
>>>> SCMI protocol is developed as better replacement to the existing SCPI
>>>> which is not flexible and easily extensible.
>>>>
>>>> Cc: Rob Herring <robh+dt@...nel.org>
>>>> Cc: Mark Rutland <mark.rutland@....com>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@....com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/arm,scmi.txt | 193 +++++++++++++++++++++
>>>>  1 file changed, 193 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
>>>> new file mode 100644
>>>> index 000000000000..d6e4b7eff199
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
>>>> @@ -0,0 +1,193 @@
>>>> +System Control and Management Interface (SCMI) Message Protocol
>>>> +----------------------------------------------------------
>>>> +
>>>> +The SCMI is intended to allow agents such as OSPM to manage various functions
>>>> +that are provided by the hardware platform it is running on, including power
>>>> +and performance functions.
>>>> +
>>>> +This binding is intended to define the interface the firmware implementing
>>>> +the SCMI as described in ARM document number ARM DUI 0922B ("ARM System Control
>>>> +and Management Interface Platform Design Document")[0] provide for OSPM in
>>>> +the device tree.
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible : shall be "arm,scmi"
>>>
>>> Convince me that this genericish string is specific enough.
>>>
>>
>> Now that you raised this point, I think we generate so many 4 letter
>> acronyms that it can collide. How about "arm,sys-ctl-mgmt-if"
> 
> I was more concerned about needing versioning or vendor specific
> compatible strings that we needed with SCPI. Is there a spec version
> or is that discoverable?
> 

Ah ok, it's discoverable and each protocol must implement
PROTOCOL_VERSION. We have specification version implemented, vendor id
and firmware implementation version all of which is mandatory.

>>>> +- method : The method of calling the SCMI firmware. Only permitted value
>>>> +       currently is:
>>>> +       "mailbox-doorbell" : When mailbox doorbell is used as a mechanism
>>>> +                            to alert the presence of a messages and/or
>>>> +                            notification
>>>> +- 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
>>>> +      supported.
>>>> +- mbox-names: shall be "tx" or "rx"
>>>
>>> ...and optionally "rx"
>>>
>>
>> OK
>>
>>>> +- shmem : List of phandle pointing to the shared memory(SHM) area between the
>>>> +      processors using these mailboxes for IPC, one for each mailbox
>>>> +      SHM can be any memory reserved for the purpose of this communication
>>>> +      between the processors.
>>>
>>> Maybe the mailbox binding should have a standard property for this?
>>>
>>
>> Do you mean as part of it's client binding ? If so, agreed. I can come
>> up with that proposal.
> 
> Yes.

Thanks, will do.

-- 
Regards,
Sudeep