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]

Date:   Thu, 25 May 2017 12:30:38 +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 24/05/17 11:56, Jassi Brar wrote:
> On Wed, May 24, 2017 at 3:46 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>>
>> Hi,
>>
>> This series adds doorbell support to ARM MHU mailbox controller driver.
>> Since we need to callback the different client based on the doorbel bits
>> triggered from the remote, we can manage with single channel for the set
>> of 32 doorbells.
>>
>> Regards,
>> Sudeep
>>
>> v1->v2:
>>         - Removed the notion od subchannels
>>         - Treat each bit in the MHU register as a doorbell and hence
>>           different channel with respect to mailbox framework
>>
> Whatever happened to the endless explanations I gave you, how the MHU
> driver already supports your usecase?
> 

Yes but you didn't respond to my queries:
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.

2. How do we call multiple clients from mhu_irq ? I have Slot/bit 0
   being used by SCPI protocol(already in mainline) and slot 1/2 or more
   will be used by SCMI ?

3. We already have mailbox-sti.c which implements exactly the same logic
   of doorbell. Why did you not push back to implement something like
   arm_mhu.c then ? I am confused as why you are so particular in this
   case ?

Few more things to note here:

1. Just because the platform you worked used MHU to pass the command
   doesn't mean that's the only one use-case and others have to
   workaround in the client drivers.

2. Read the specification again. It's clear that it's designed for
   doorbell kind of usage. All I am asking is to support that both in
   the binding and implementation. And lets not assume or make it work
   with one protocol. It's generic IP and can be used in either
   doorbell way or the way it's currently supported.

3. That's one of the reason for just have 2 set's of registers as it's
   possible to use them as 32 different doorbells. Otherwise 2 channels
   is too limited for any platform.

Please address my queries instead of claiming that you can workout a
solution. I simply want the mailbox and protocol independent and hence
the binding. I don't like the idea of you proposed(i.e. 32-bit data to
be written to the controller register).

-- 
Regards,
Sudeep