linux-kernel - Re: [PATCH] firmware: meson-sm: use generic compatible

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, 19 Oct 2017 16:18:17 -0500
From:   Rob Herring <robh@...nel.org>
To:     Kevin Hilman <khilman@...libre.com>
Cc:     Jerome Brunet <jbrunet@...libre.com>,
        Carlo Caione <carlo@...one.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-amlogic@...ts.infradead.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: meson-sm: use generic compatible

On Thu, Oct 19, 2017 at 5:25 AM, Kevin Hilman <khilman@...libre.com> wrote:
> Rob Herring <robh@...nel.org> writes:
>
>> On Thu, Oct 12, 2017 at 03:47:43PM +0200, Jerome Brunet wrote:
>>> The meson secure monitor seems to be compatible with more SoCs than
>>> initially thought. Let's use the most generic compatible he have in
>>> DT instead of the gxbb specific one
>>>
>>> Signed-off-by: Jerome Brunet <jbrunet@...libre.com>
>>> ---
>>>  Documentation/devicetree/bindings/firmware/meson/meson_sm.txt | 4 ++--
>>>  drivers/firmware/meson/meson_sm.c                             | 4 ++--
>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> Seems like a pointless, not backwards compatible change to me.
>
> I've verified that it's backwards compatible with existing upstream DTs.

Perhaps if you all are documenting only what the driver uses, not what
the dts can have as Jerome said.

>> end, it's just a string to match on. Who cares what the string is.
>
> As platform maintiner, I very much care what the strings are and I want
> it to be coherent with the platform generic names, and I want the
> SoC-specific strings to correspond to the actual SoC names.

The most specific compatible should be, absolutely. The fallbacks can
be anything really. Ideally, they are the compatible string for the
1st SoC with "the same" compatible IP. Could be another vendor
entirely even because mergers happen.

Rob