linux-kernel - Re: [PATCH v2 08/12] ARM: dts: imx6dl-pico: fix board compatibles

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:   Fri, 2 Oct 2020 10:20:12 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc:     Rob Herring <robh+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Anson Huang <Anson.Huang@....com>,
        Andreas Kemnade <andreas@...nade.info>,
        Stefan Riedmueller <s.riedmueller@...tec.de>,
        Robert Jones <rjones@...eworks.com>,
        Li Yang <leoyang.li@....com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 08/12] ARM: dts: imx6dl-pico: fix board compatibles

On Fri, Oct 02, 2020 at 09:41:28AM +0200, Ahmad Fatoum wrote:
> Hello,
> 
> On 10/1/20 12:37 PM, Krzysztof Kozlowski wrote:
> >> The existing binding doesn't cover these boards then and needs to be
> >> extended, no? How about following patch?
> > 
> > What do you mean it doesn't cover? It was added exactly to handle them:
> > +              - technexion,imx6q-pico-dwarf   # TechNexion i.MX6Q Pico-Dwarf
> > +              - technexion,imx6q-pico-hobbit  # TechNexion i.MX6Q Pico-Hobbit
> > +              - technexion,imx6q-pico-nymph   # TechNexion i.MX6Q Pico-Nymph
> > +              - technexion,imx6q-pico-pi      # TechNexion i.MX6Q Pico-Pi
> > 
> 
> Still they are unused. So I'd think these boards should be handled like boards
> that predated bindings: a binding is written that doesn't break existing users.

OK, let's assume the binding is not correct and DTSes are good.

> 
> >> [I guess we need to keep the two-compatible list they were originally
> >>  in for compatibility even if it's unused among upstream device trees?]
> > 
> > You want to change both the binding (thus breaking the ABI) and update
> > the DTS to reflect new ABI. Then why having a binding at all?
> 
> If we leave the old two-compatible enumeration intact, there is no ABI broken.

Just to clarify, because I don't get here the "no ABI broken" part:
ABI is the binding, not the DTS. We can change intree DTS as we like,
replace compatibles, add nodes, remove nodes. There is no stability
requirement for DTS contents.

If we leave two-compatible binding intact, it is a broken binding since
beginning. Removing non-working, fake ABI is not breaking it because it
could never work.

> 
> > I would assume that either binding is correct or DTS. You propose that
> > both are wrong and both need changes... in such case this is clearly
> > broken.
> 
> IMO the DTS is the correct one. If you want to honor the author's intention
> that each base board has a different compatible, it should be an extra
> compatible and not replace the existing one that may be already in use.

OK, we can go with DTS approach. I fixed few of such cases as well,
assuming that DTS was intended and binding was incorrect. In such case
all boards will be documented under one compatible technexion,imx6q-pico
and DTS will not be changed.

Best regards,
Krzysztof