Date:   Tue, 14 Dec 2021 11:11:25 +0000
Message-ID: <877dc7jvaa.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Rob Herring <robh+dt@kernel.org>,
        Shawn Guo <shawnguo@kernel.org>, Leo Li <leoyang.li@nxp.com>,
        Biwen Li <biwen.li@nxp.com>, "Z.Q. Hou" <zhiqiang.hou@nxp.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [RFC PATCH devicetree 00/10] Do something about ls-extirq interrupt-map breakage
In-Reply-To: <20211214105316.aibjmwdhg7a5wwlj@skbuf>
References: <20211214013800.2703568-1-vladimir.oltean@nxp.com>
        <87ilvrk1r0.wl-maz@kernel.org>
        <20211214095853.4emzycaxkuqr4tun@skbuf>
        <87czlzjxmz.wl-maz@kernel.org>
        <20211214103025.wnzkfxr5xxeuhpln@skbuf>
        <87a6h3jwrc.wl-maz@kernel.org>
        <20211214105316.aibjmwdhg7a5wwlj@skbuf>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Tue, 14 Dec 2021 10:53:16 +0000,
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> 
> On Tue, Dec 14, 2021 at 10:39:35AM +0000, Marc Zyngier wrote:
> > On Tue, 14 Dec 2021 10:30:26 +0000,
> > Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> > > 
> > > 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@nxp.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.
> > 
> > maz@hot-poop:~/arm-platforms$ git describe --contains 869f0ec048dc --match=v\*
> > v5.16-rc1~125^2~19^2~16
> > 
> > This patch landed in -rc1, and isn't part of any release. Just revert
> > it, and no damage is done.
> 
> The revert is one of the patches posted here. It will fix the problem
> short-term but it may not be enough long-term. I think Rob is working on
> some sort of validation for "interrupt-map" and this is how the apparently
> non-conformant property was brought to his attention. It will trigger
> validation warnings that I'm afraid will be tempting for many to "fix".

Then build an annotation mechanism for the warning not to fire for
quirked systems.

> Thus the rest of the patches. Maybe it's just me, but between having to
> play a whack-a-mole game and snapping compatibility of old kernels with
> new DT blobs, I think more time is lost with the latter.

I said what I had to say on the subject, and when it comes to wasted
time, that's more than enough.

	M.

-- 
Without deviation from the norm, progress is not possible.