linux-kernel - Re: [PATCH] mailbox: add support for doorbell/signal mode controllers

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] [day] [month] [year] [list]

Date:   Thu, 2 Nov 2017 20:22:14 +0530
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Arnd Bergmann <arnd@...db.de>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH] mailbox: add support for doorbell/signal mode controllers

On Thu, Nov 2, 2017 at 6:07 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> On 02/11/17 12:21, Jassi Brar wrote:
>> On Thu, Nov 2, 2017 at 5:19 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>>> On 02/11/17 11:26, Jassi Brar wrote:
>>
>>>>>> 1) Where does the  "whatever_value_to_trigger_signal"  come from?
>>>>>
>>>>> Controller specific.
>>>>>
>>>>>> That has to come from client.
>>>>>
>>>>> No.
>>>>>
>>>> Again, let me know what does the controller expect 'val' to be
>>>>
>>>>   writel(val, MAILBOX_A2B_CMD(chans->idx))
>>>>
>>>
>>> It depends on the controller. Whatever value that can generate a signal
>>> to remote.
>>>
>> As you _know_, the controller expects any non-zero value. Now what
>> value would you write in there?
>>
>
> I just said its *non-zero value* to give example. What action needs to
> be done to trigger the doorbell is *entirely* controller specific and
> typically it's a bit in the register.
>
Please read the above full context and see how you wasted 4 posts just
because you had to refute my any explanation.

>>>
>>> 1. pcc_send_data (drivers/mailbox/pcc.c)
>>> 2. sti_mbox_send_data (drivers/mailbox/mailbox-sti.c)
>>> 3. qcom_apcs_ipc_send_data (drivers/mailbox/qcom-apcs-ipc-mailbox.c)
>>> 4. tegra_hsp_doorbell_send_data (drivers/mailbox/tegra-hsp.c)
>>>
>>> And SCMI fits the above case.
>>>
>> These are only 4 out of 14. Can we overlook that your implementation
>> rules out 70% controllers.
>>
>
> I am *not* saying we will break other 10 controllers. All I am says
> there are 4 controllers that can make use of this new feature. 4 is good
> number IMO to generalize something.
>
If all you want to support is these 4 controllers why mess with the api?!

These 4 controllers don't use the data pointer, just use the existing
API as such
  mbox_send_message(chan, NULL);


>> BTW these 4 don't even need any send_signal() api, they would remain
>> unchanged. What's the new api for?
>>
>
> Sure, it's working fine doesn't mean it can't be used at all. That's not
> a right argument TBH.
>
API real estate is very precious. No redundancy should be added,
unless absolutely necessary.