linux-kernel - Re: [RFC PATCH devicetree 00/10] Do something about ls-extirq interrupt-map breakage

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: <20211214103025.wnzkfxr5xxeuhpln@skbuf>
Date:   Tue, 14 Dec 2021 10:30:26 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Marc Zyngier <maz@...nel.org>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>, Leo Li <leoyang.li@....com>,
        Biwen Li <biwen.li@....com>, "Z.Q. Hou" <zhiqiang.hou@....com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: Re: [RFC PATCH devicetree 00/10] Do something about ls-extirq
 interrupt-map breakage

On Tue, Dec 14, 2021 at 10:20:36AM +0000, Marc Zyngier wrote:
> On Tue, 14 Dec 2021 09:58:54 +0000,
> Vladimir Oltean <vladimir.oltean@....com> wrote:
> > 
> > Hi Marc (with a c),
> > 
> > I wish the firmware for these SoCs was smart enough to be compatible
> > with the bindings that are in the kernel and provide a blob that the
> > kernel could actually use. Some work has been started there and this is
> > work in progress. True, I don't know what other OF-based firmware some
> > other customers may use, but I trust it isn't a lot more advanced than
> > what U-Boot currently has :)
> > 
> > Also, the machines may have been in the wild for years, but the
> > ls-extirq driver was added in November 2019. So not with the
> > introduction of the SoC device trees themselves. That isn't so long ago.
> > 
> > As for compatibility between old kernel and new DT: I guess you'll hear
> > various opinions on this one.
> > https://www.spinics.net/lists/linux-mips/msg07778.html
> > 
> > | > Are we okay with the new device tree blobs breaking the old kernel?
> > |
> > | From my point of view, newer device trees are not required to work on
> > | older kernel, this would impose an unreasonable limitation and the use
> > | case is very limited.
> 
> My views are on the opposite side. DT is an ABI, full stop. If you
> change something, you *must* guarantee forward *and* backward
> compatibility. That's because:
> 
> - you don't control how updatable the firmware is
> 
> - people may need to revert to other versions of the kernel because
>   the new one is broken
> 
> - there are plenty of DT users beyond Linux, and we are not creating
>   bindings for Linux only.
> 
> You may disagree with this, but for the subsystems I maintain, this is
> the rule I intent to stick to.

That's an honorable set of guiding principles, but how do you apply them
here? Reverting Rob's change won't fix the past, and updating the code
to account for one format will break the other. As for trying one
format, and if there's an error try the other, there may be situations
in which you accept invalid input as valid.