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]

Date:   Thu, 6 Jul 2017 10:18:39 +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

Hi Jassi,

On 06/07/17 07:28, Jassi Brar wrote:
> On Wed, Jul 5, 2017 at 11:32 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> 
>>
>> I have posted the SCMI patches now[1],
>>
> I wish I was CC'ed on that. Now LKML seems too busy to forward it.
> 

Yes, my mistake, I should have cc-ed you.

>> please let me know how to get
>> both SCPI and SCMI working together with different doorbell bits on the
>> same channel.
>>
> You say in the cover letter :
> "Let me begin admitting that we are introducing yet another protocol to
> achieve same things as many existing protocols like ARM SCPI, TI SCI,
> QCOM RPM, Nvidia Tegra BPMP, and so on"
> 
>  So SCMI is supposed to replace SCPI, SCI, RPM and BPMP   or   SCMI is
> to be used for future platforms.
> If SCPI and SCMI achieve the same, why have them both active simultaneously?
> 

Yes it may not be used, but the firmware might support both for backward
compatibility. E.g. on Juno, we still may continue supporting SCPI while
we transition to SCMI. So both old and new DTs must work.

> Assuming there really is some sane excuse :-

Yes as I mentioned above.

>     SCPI and SCMI are two separate client working over an MHU channel.
> So, as is the case with users relying on a common resource, you need a
> shim arbitrator that serialises access to the resource.>

Yes, that's what I have done with this series of patches retaining the
backward compatibility. I have made it generic to ARM MHU instead of
specifically addressing couple of protocols on a particular platform.

If I try to come up with an additional shim driver, I bet it will become
much ugly, bigger and platform specific.

The specification of MHU mentions on how to use it as doorbell bit and I
am doing that to provide cleaner and generic solution which I you seem
to disagree with. So please suggest/provide alternative solution.

A shim layer may get complicated as both SCMI and SCPI will call
standard mailbox APIs. Do you mean I need to replace those calls with
shim layer API ? If I do that it may break on other platforms which are
using SCPI.

-- 
Regards,
Sudeep