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

[Marc Zyngier]

On Tue, 14 Dec 2021 10:30:26 +0000,
Vladimir Oltean <vladimir.oltean at 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 at 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 at 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.

	M.

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