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: <e14806c9-068b-028d-b053-89c51cc43d95@arm.com>
Date:   Thu, 5 Oct 2017 15:10:24 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jassi Brar <jassisinghbrar@...il.com>,
        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>,
        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 14:20, Jassi Brar wrote:
> On Wed, Oct 4, 2017 at 5:35 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>>> On 04/10/17 11:50, Arnd Bergmann wrote:
>>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> 
>>
>>>>> +- shmem : List of phandle pointing to the shared memory(SHM) area as per
>>>>> +         generic mailbox client binding.
>>>>> +
>>>>> +See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
>>>>> +about the generic mailbox controller and client driver bindings.
>>>>> +
>>>>> +The mailbox is the only permitted method of calling the SCMI firmware.
>>>>> +Mailbox doorbell is used as a mechanism to alert the presence of a
>>>>> +messages and/or notification.
>>>>
>>>> This looks odd: why not make the message itself part of the mailbox
>>>> protocol here, and leave the shmem as a implementation detail of the
>>>> mailbox driver?
>>>>
>>>
>>> I am not sure if I follow you here. But generally shmem can be memory
>>> carved out of anything in the system and it's dependent on the protocol
>>> and the remote firmware rather than the mailbox hardware itself.
>>
>> I think the problem is the way we use the mailbox API in Linux, which
>> is completely abstract at the moment: it could be a pure doorbell, a
>> single-register for a data, some structured memory, or a
>> variable-length message. The assumption today is that the mailbox
>> user and the mailbox driver agree on the interpretation of that
>> void pointer.
>>
> The way controllers and remote firmwares are paired there is no other
> way to write reusable code.
> 
>> This breaks down here, as you require the message to be a
>> variable-length message in a fixed physical location, but assume that
>> the mailbox serves only as a doorbell.
>>
> That is a valid usecase, already supported. There's an optional
> callback provided by the api to fill SHMEM
> mbox_chan->mbox_client->tx_prepare()
> 

Thanks, I missed to mention this earlier. But the point here is to avoid
the shim layer with each protocol for most common use case like doorbell.

But what I understood from Arnd's suggestion is to have another API
which just *sends signal* _rather_than_ *send data" to identify between
the two.
-- 
Regards,
Sudeep