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

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
Date: Tue, 14 Dec 2021 10:20:36 +0000	[thread overview]
Message-ID: <87czlzjxmz.wl-maz@kernel.org> (raw)
In-Reply-To: <20211214095853.4emzycaxkuqr4tun@skbuf>

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.

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel