linux-kernel - Re: [PATCH 2/6] Documentation: devicetree: add bindings to support ARM MHU subchannels

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: <bca5e8bd-3c18-6ed4-2a74-eee513ddc41d@arm.com>
Date:   Tue, 9 May 2017 11:53:20 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Sudeep Holla <sudeep.holla@....com>, Rob Herring <robh@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexey Klimov <alexey.klimov@....com>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH 2/6] Documentation: devicetree: add bindings to support
 ARM MHU subchannels

On 09/05/17 11:31, Jassi Brar wrote:
> On Tue, May 9, 2017 at 3:28 PM, Sudeep Holla <sudeep.holla@....com>
> wrote:
> 
>>> 
>>> If it is still not clear, please share your client driver. I
>>> will adapt that to work with existing MHU driver & bindings.
>>> 
>> 
>> Just take example of SCPI in the mainline. Assume there's another 
>> protocol SCMI which uses few more bits in the same channel and the 
>> remote firmware implements both but both are totally independent
>> and not related/linked. Also be keep in mind that SCPI is used by
>> other platforms and so will be the new protocol. We simply make
>> SCPI or SCMI bindings aligned to ARM MHU. That's ruled out.
>> 
> Not sure what you mean by "that's ruled out".

1. The mailbox client bindings should be independent of this ARM MHU
   mailbox bindings
2. All we need in client is a mailbox to point at and not any meta data
   That's what I meant by ruled-out as both client and MHU can be used
   independent of each other and *should not* be linked.

> Anyways, to be clear, the bindings must remain same as long as the
> h/w doesn't change.

While I would generally agree with that, but since the existing binding
didn't consider the possibility of using it as sub-channels, I disagree
with your opinion now.

> It is the client driver (DT node) that should be versioned for SCPI
> or SCMI based on what the platform supports.

Why ? All that client care is about doorbell.

> I have tried many ways to explain how to implement it and apparently 
> failed. So lets talk code.

OK

> You have already shared this "v2" MHU driver, now please also share 
> your client driver. I'll make it work with original MHU driver and 
> that should settle your confusion.

It should first work with SCPI in the mainline. Then we will add another
similar protocol soon. So I think you have all you need in the mainline.
Today we have hack in the SCPI driver to pass bit 0 set in data. But
that's broken as we may want different slot on some other platform.
Basically SCPI is designed with the use of doorbell and it should not
have any details on how to write that into a particular register as
along as we just choose the right channel.

On digging more about different mailbox controllers, I found
mailbox-sti.c has exactly similar logic as what I have done in this series.

Also don't mix implementation with the binding. I need a simple answer
in this binding. How do I represent specific bits if each bit is
implemented as a doorbell ? That's all. First let's agree on that when
we use this mailbox independently and please *don't mix* with any
client here. It's simple, this controller has 2-3 sets of 32 doorbell
bits. And I am aiming to come up with the binding for that as your
initial bindings didn't consider that.

-- 
Regards,
Sudeep

-- 
Regards,
Sudeep