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

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: <36ea8010-f22a-e0d9-b9a9-bb6be19db45d@arm.com>
Date:   Thu, 6 Jul 2017 17:44:50 +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>,
        Devicetree List <devicetree@...r.kernel.org>,
        Alexey Klimov <alexey.klimov@....com>,
        Jassi Brar <jaswinder.singh@...aro.org>
Subject: Re: [PATCH v2 2/6] Documentation: devicetree: add bindings to support
 ARM MHU doorbells



On 06/07/17 15:37, Jassi Brar wrote:
> On Thu, Jul 6, 2017 at 3:03 PM, Sudeep Holla <sudeep.holla@....com> wrote:

[...]

>>
>> I said it *may not be used*, currently it is used.
>>
> SCPI provides more than what SCMI currently does - dvfs, clock, sensor.

Not sure what you mean by that, but that's not true.

> I see no reason why you must have SCPI and SCMI both running.
> 

We can still have 2 different protocols using same MHU channel with
different doorbells, what's wrong with that ?

> And even then there is a solution - a shim arbitrator. Other
> platforms, those share a channel, do that. No big deal.
> 

Example please ? Please remember these protocols are generic and we
can't add any platform specific code into them.

>  BTW, I hope you realise that we need a 'transport layer' which will
> be the platform specific glue between mailbox controller specifics and
> the generic SCMI code.

Why ? Clearly you have not made a since technical argument so far as why
MHU doorbell is not correct way even when MHU specification is clearly
allows it. I have given example of ST mailbox which has this doorbell
kind of support.

> I see your confusion in the form of some issues in the SCMI
> implementation, please CC me on the next revision.
> 

Care to elaborate on what's my confusion or at-least what you think so ?

Also if you have concern on implementation, ok we can discuss further.
But can you make it clear as what your objections are for the doorbell
MHU binding. How will I get the bit assigned for different protocols
which are platform specific ? I still need some binding , right ?
-- 
Regards,
Sudeep