linux-kernel - Re: [PATCH v2 0/6] mailbox: arm_mhu: add support for doorbell mode

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: <7291e5d7-fb63-57cf-c029-7a9f3b757c35@arm.com>
Date:   Thu, 25 May 2017 14:53:33 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Alexey Klimov <alexey.klimov@....com>
Subject: Re: [PATCH v2 0/6] mailbox: arm_mhu: add support for doorbell mode



On 25/05/17 14:44, Jassi Brar wrote:
> On Thu, May 25, 2017 at 7:05 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>>>> 1. The client driver is generic and expects it to be doorbell like
>>>>    mailbox controller. I am referring to SCMI which will be released
>>>>    soon. We can't embed ARM MHU or any other mailbox controller info
>>>>    into that.
>>>>
>>> If SCMI is to be usable over different platforms, there has to be 2
>>> sub-parts of the SCMI - one platform agnostic high level protocol
>>> implementation, and the other platform specific 'transport' layer
>>> where actual message xfer is done.
>>>
>>
>> It recommends doorbell kind of interface for the transport.
>>
>>> For the Nth time:-
>>>     The 'mssg' in mbox_send_message(struct mbox_chan *chan, void
>>> *mssg) is platform specific. For MHU it is simple u32*, whereas for
>>> other platform it will be like 'struct my_protocol_message *'
>>>
>>> I can't make it any clearer.
>>>
>>
>> Why is that ? Just because it was used on your platform like that ?
>> Sorry that's not a valid reason.
>>
> To be clear, by "other platform" I mean platforms with mailbox
> controller other than MHU.  (Not to mean SCMI can't run on MHU as of
> today).
> 

It can't run along with existing SCPI without some hacking. You need to
add a layer that is platform specific which is *hacky*.

> Do you intend SCMI to run only on platforms that have MHU controller?
> I hope not.
> 

Definitely not, that's the whole point. It should work with any
controller that supports doorbell mode.

> Now re-read my last post until you get it.
> 
Just propose the binding yourself.

On juno, say we will use low priority channel

BIT(0) - SCPI
BIT(1) - SCMI (general)
BIT(2) - SCMI (notification)
BIT(3) - A totally new protocol
:
:
with each of the above with specific shared memory reserved for them.

Beware we don't need any of these info in either of the driver as it
may change with another platform. So this info has to come from DT.
So I am requesting you to propose the binding if you think you can
better than the one I have.

I can base my code on that.

-- 
Regards,
Sudeep