linux-kernel - Re: [PATCH] firmware: arm_scmi: Make scmi core independent of transport type

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: <CAK8P3a3wnn3E9DEfAoXNAurZ3Yop-Y3d_9+3mARY2v5y2B5dAw@mail.gmail.com>
Date:   Thu, 9 Jan 2020 11:15:09 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Sudeep Holla <sudeep.holla@....com>, peng.fan@....com,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] firmware: arm_scmi: Make scmi core independent of
 transport type

On Thu, Jan 9, 2020 at 10:34 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 09-01-20, 09:18, Arnd Bergmann wrote:
> > On Fri, Nov 29, 2019 at 10:32 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:

> > This looks odd: rather than guessing the transport type based on
> > random DT properties, I would prefer to have it determined by
> > the device compatible string, and have different drivers bind
> > to one of them each, with each driver linking against a common
> > base implementation, either as separate modules or in one file.
>
> Since there are no platforms using the scmi binding in mainline kernel
> for now, it won't be difficult to add new compatible strings. So
> should this be done like:
>
>         compatible = "arm,scmi", "arm,scmi-mailbox";
>
> or just
>         compatible = "arm,scmi-mailbox";

I would keep compatibility with the existing binding and make a plain "arm,scmi"
mean the version with the mailbox, while for new transports, I would
require them to have both the existing compatible string and a more specific
one.

        Arnd