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: <cd57b90c-4250-64df-9142-d12ac7ed7ad3@arm.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ