linux-kernel - Re: [PATCH v3 02/22] dt-bindings: arm: add support 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <19eca9f4-5606-5849-12f1-5480d89b95e7@arm.com>
Date:   Thu, 5 Oct 2017 13:56:28 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Arnd Bergmann <arnd@...db.de>
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>, Loc Ho <lho@....com>,
        Alexey Klimov <alexey.klimov@....com>,
        Ryan Harkin <Ryan.Harkin@....com>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH v3 02/22] dt-bindings: arm: add support for ARM System
 Control and Management Interface(SCMI) protocol



On 05/10/17 12:56, Arnd Bergmann wrote:
> On Wed, Oct 4, 2017 at 4:47 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>> On 04/10/17 15:17, Arnd Bergmann wrote:
>>> On Wed, Oct 4, 2017 at 3:53 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>>>> On 04/10/17 13:35, Arnd Bergmann wrote:
>>>>> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> 
>>> There are probably several ways of doing this better, we should see
>>> what the best is we can come up with.
>>>
>>> I think generally speaking we need a way for a mailbox user to
>>> know what it should use as the mailbox data here, so it is
>>> able to talk to different incompatible mailbox providers.
>>>
>>> One idea I had is to use a nested mailbox driver, that turns
>>> a doorbell or single-register styled mailbox into a variable-length
>>> mailbox by adding a memory region, like
>>>
>>>     mailbox@...3000 {
>>>         compatible = "vendor-hardware-specifc-id";
>>>         interrupts = <34>;
>>>         reg = <0x1233000 0x100>;
>>>         #mbox-cells = <1>;
>>>     };
>>>
>>>     mailbox {
>>>            compatible = "shmem-mailbox";
>>>            mboxes = <&/mailbox@...3000  25>;
>>>            #mbox-cells = <1>;
>>>            shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
>>>     };
>>>
>>> This would create one mailbox that only takes a register argument,
>>> and another one that can take longer messages based on the first.
>>> In your driver, you then refer to the second one and pass the
>>> variable-length data into that directly.
>>
>> 1. IIUC it was intentional not to include shmem as part of mailbox
>>    controller binding and was pushed to client drivers as it's generally
>>    not part of mailbox IP block. I am not sure if there are any other
>>    specific reasons for that, but I may be missing some facts.
> 
> Ok, I see.
> 
>> 2. I am not sure if we need nested driver/bindings (at-least to begin
>>    with). On a platform I don't think both/all modes will be used.
>>    I had  proposal for adding doorbell for ARM MHU based on extended
>>    bindings, but it was rejected[1]. But I really preferred that over
>>    the shim layer I had to add in v3.
> 
> Maybe we can come up with a more generic way to do doorbells
> on top of mailboxes instead? This sounds like a problem that
> would come back with other drivers, so the MHU-specific shim
> will not be a permanent solution either.
> 

I completely agree. I have seen few drivers that just implement
doorbells in their controller. I will check them in details again.

-- 
Regards,
Sudeep