linux-kernel - Re: [PATCH v10 2/6] dt-bindings: gpio: logicvc: Add a compatible with major version only

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Feb 2022 14:26:28 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc:     devicetree@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-gpio@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH v10 2/6] dt-bindings: gpio: logicvc: Add a compatible with
 major version only

On 2022-01-30 00:46, Linus Walleij wrote:
> On Thu, Jan 20, 2022 at 4:00 PM Paul Kocialkowski
> <paul.kocialkowski@...tlin.com> wrote:
> 
>> There are lots of different versions of the logicvc block and it
>> makes little sense to list them all in compatibles since all versions
>> with the same major are found to be register-compatible.
> 
> The reason we try to be precise is because sometime, long after the driver
> has been merged and maintained for a few years, a bug is discovered
> in a specific version of the silicon.
> 
> What happens is that a fix is applied on all silicon whether it is needed
> or not.
> 
> If you have the precise silicon compatible, you can avoid this and target
> only a specific version.

Indeed, the better approach would be something like:

   compatible:
     oneOf:
       - items:
           - enum:
               - foo,bar-v1.0
               - foo,bar,v1.1
           - const: foo,bar-v1
       - items:
           - enum:
               - foo,bar-v2.0
           - const: foo,bar-v2

That way the DTs are future-proof, while drivers can still match on only 
the less-specific strings until a need arises. Plus it avoids the 
problem that if an existing OS that only understands "foo,bar-v1.0" is 
given a new DT with only "foo,bar-v1" for v1.0 hardware it won't be able 
to use the device, even though it's *functionally* capable of doing so.

However, from skimming patch #5, it looks possible that none of these 
changes are needed at all. If LOGICVC_IP_VERSION_REG tells you the exact 
revision, and is always present (as the unconditional reading of it 
implies), then the only reason for adding new compatibles would be if, 
say, v5 has more clocks from v4 and you want the binding to enforce 
that; otherwise, newer versions are literally compatible with the 
currently-defined binding and therefore should continue to bind against 
the existing string(s) to maximise forward- and backward-compatibility. 
Sure, it's not the prettiest thing for a "generic" compatible to be 
based on an oddly-specific version number that doesn't necessarily match 
the actual software-discoverable version, but what's done is done and 
that's the cost of ABI.

Cheers,
Robin.

(also, nitpick for that part of patch #5 since I'm here: please include 
linux/bitfield.h rather than reinventing FIELD_GET() locally)