linux-kernel - Re: [PATCH v3 03/22] dt-bindings: arm: scmi: add ARM MHU specific mailbox client bindings

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 Oct 2017 08:52:35 -0500
From:   Rob Herring <robh@...nel.org>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        ALKML <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Roy Franz <roy.franz@...ium.com>,
        Harb Abdulhamid <harba@...eaurora.org>,
        Nishanth Menon <nm@...com>, Arnd Bergmann <arnd@...db.de>,
        Loc Ho <lho@....com>, Alexey Klimov <alexey.klimov@....com>,
        Ryan Harkin <Ryan.Harkin@....com>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH v3 03/22] dt-bindings: arm: scmi: add ARM MHU specific
 mailbox client bindings

On Fri, Oct 6, 2017 at 9:26 PM, Jassi Brar <jassisinghbrar@...il.com> wrote:
> On Fri, Oct 6, 2017 at 9:24 PM, Rob Herring <robh@...nel.org> wrote:
>> On Fri, Oct 6, 2017 at 6:01 AM, Jassi Brar <jassisinghbrar@...il.com> wrote:
>>> On Fri, Oct 6, 2017 at 4:50 AM, Rob Herring <robh@...nel.org> wrote:
>>>> On Thu, Sep 28, 2017 at 02:11:27PM +0100, Sudeep Holla wrote:
>
>>>>
>>>>> +- mbox-data : For each phandle listed in mboxes property, an unsigned 32-bit
>>>>> +           data as expected by the mailbox controller
>>>>
>>>> Shouldn't that be cells as part of mboxes property?
>>>>
>>> A MHU client can send any number of commands (such u32 values) over a channel.
>>> This client (SCMI) sends just one command over a channel, but other
>>> clients may/do send two or more.

The above definition doesn't support 2 or more as it is 1-1 with channels.

>> Okay, then I guess I don't understand why this is in DT.
>>
> Yeah the client has to provide code (u32 value) for the commands it
> sends, and that value is going to be platform specific. For example,
> on Juno the ITS_AN_SCMI_COMMAND may be defined as BIT(7) while on my
> platform it may be 0x4567
>
> For MHU based platforms, it becomes easy if the u32 is passed from DT.
> And that should be ok since that is like a h/w parameter - a value
> chosen/expected by the remote firmware.

Could it ever be more than 1 cell?

I guess being in DT is fine, but I'm still not sure about the naming.
The current name suggests it is part of the mbox binding. Do we want
that or should it be SCMI specific? Then "data" is vague. Perhaps
"scmi-commands"?

Rob