linux-kernel - Re: [PATCH v3 16/22] firmware: arm_scmi: add arm

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: <CAOCOHw54mQUVxVyLRWbV5Ty7trK99MM6zgXsuuxQEHnD3qvKVA@mail.gmail.com>
Date:   Thu, 12 Oct 2017 14:03:56 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Jassi Brar <jassisinghbrar@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        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>
Subject: Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On Fri, Oct 6, 2017 at 6:51 AM, Sudeep Holla <sudeep.holla@....com> wrote:
>
>
> On 06/10/17 14:47, Jassi Brar wrote:
>> On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla <sudeep.holla@....com> wrote:
[..]
>>> Again that's not the point, doorbell is more common feature and that can
>>> be supported. As SCMI expects doorbell feature in the specification, it
>>> just need to support that class of controllers.
>>>
>> NO.  All SCMI expects is SHMEM and a signal reaching the other end.
>> The signal mechanism need not necessarily be "doorbell".
>>
>
> Agreed, but creating an abstraction ro do something as generic as
> doorbell and writing shim layer for each controller to use SCMI also
> sounds bad.
>

In the Qualcomm platform we have a single register that exposes 32
doorbells, wired to interrupts on the various processors/co-processors
in the SoC.

There is a handful of different clients each using these doorbells to
inform the other side that something has happened (often that some
piece of shared memory has been filled with data). Over the years
(platforms) this register has moved around as such multiple
implementations exists.

You can see an example of this in
drivers/mailbox/qcom-apcs-ipc-mailbox.c and e.g.
drivers/rpmsg/qcom_glink_native.c (qcom_glink_rpm.c prior to v4.14).

I'm struggling to figure out exactly how your case looks like, but if
your doorbell exists in only one instance and there is only one client
then I would suggest that it's overkill to create another driver for
it.

Regards,
Bjorn