From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Marc Zyngier <maz@kernel.org>
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
Thread-Topic: [RFC PATCH devicetree 00/10] Do something about ls-extirq
 interrupt-map breakage
Thread-Index: AQHX8ItO3xtQxxPJV0yONti9mp5846wxrpCAgAASv4CAAAYSAIAAAr6AgAACkICAAAPSAA==
Date:   Tue, 14 Dec 2021 10:53:16 +0000
Message-ID: <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>
In-Reply-To: <87a6h3jwrc.wl-maz@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?57b3U+EkUGvhFdzLqg0vNkCRNGuk/Eja2hNRdahreqrZwdPye77aFUKZ6bRJ?=
 =?us-ascii?Q?lqP0q2m2+LR/NLB7hmJNd3orLDc4EkubrnZEsj/O3IdrLruOALBal6zfa58v?=
 =?us-ascii?Q?jCpv78DyDjt2alGNbQsSj1U1d8ccDvB+/2/PXwv1JqHt9k6+qxWCdadUvxSH?=
 =?us-ascii?Q?Ke8b/lVoOZ8Qrr/ULsln5AGI+al2qiruxifiwAnMTrc+6McwqWKtV2NIiyYF?=
 =?us-ascii?Q?8lPgMG6pg/1J2qW76i43fv6Z73lw9C4TN7l6k8JL9GjHZhlD3PGC2ZjhPVYU?=
 =?us-ascii?Q?Z3UAHl7w57dVbhbpWYkPggkxPc1ajPw1bDSiADl2BD5zu/qLu3b+dORf8x4Q?=
 =?us-ascii?Q?wOAfUfmchUHl/1MaDBPKHWcefbP5o4Ew7H3DE/kBE31ZDkXEO8Tc97KM3aQE?=
 =?us-ascii?Q?h/2Lbo8tI3uyu4ONGTaqWmm4ARiHGrfZEUVWJB24Bf8S6yO1NDLFhth9Xb7Z?=
 =?us-ascii?Q?HXLsfzGmWn0pipG/ETrJSYS6/fQr/G55oQGi0QyebOJIgcNdBH9YVuxfMVKv?=
 =?us-ascii?Q?DBpYvwriiBA+MI8XY+kMu/4AX4qteCwwRd+xwgLWhGfDnZ/sOl47+uNaoktD?=
 =?us-ascii?Q?/2e2dwSVD2hzgV33Oo45f6EMV5NchJonx7Q6Wyw4mQ6d0vLvNTkIQ9gXDIBL?=
 =?us-ascii?Q?/Sw+wcGMnhpoWbUrWTXhgyeYQ5TpXxwI/8p135+46sncaevTpOXP+sC8Mogm?=
 =?us-ascii?Q?DdhcRSe77oX6Vp2vLYqh8w5OVnYcUk4HgCpS1Wt08JEwwzMqdjbjS7muTsRy?=
 =?us-ascii?Q?Rt92/fJebMUlAV276ix78+0AAErDWCeyHZBAT+D0E4Sp9KNLq1su7DDFUaBO?=
 =?us-ascii?Q?Po+B9zDehn13M4Vk0R2NUr1ldS1vGQeZH/xtYa+6fVbL8KUgC7CfWGWMQT6M?=
 =?us-ascii?Q?ovecdxyYDXpOB6PKjy4ZceAVLddxMSA5Y4AC9gsVR2fmnUMDTPzo4v5bNACT?=
 =?us-ascii?Q?r+6vbMD5g76JtU5MTfD3I//N/eNtciSx7JHlfeVbfOoCV1lg4vX5W/HmCOWe?=
 =?us-ascii?Q?WKWLzBvn/pjHVL2AxD1Nob+IYjNdMexykWAkccMp4ovTLerfvuKEjuyk58zP?=
 =?us-ascii?Q?9RtVfKya98U+TzqCRGOglYuAic1gI7jEiKAsPNjhPJP6T43sqX1Eq0orZDYs?=
 =?us-ascii?Q?IVPjq4NRdBZHEQ2xc9U3d/7xk9XoatK5n669Pxg079W7FfYc0gCIL+eO3EbS?=
 =?us-ascii?Q?3/b2oBFqj3eQP0ipx8/gQItoC7wOoONgkbLz7Zi2scR+Ml4clHGTmQjWFFsn?=
 =?us-ascii?Q?z3aEbrdbu4SWnzD7KKCpJzFlMofi0jVVmt4p1m1Oc5dpgejYg1dJPH4ozfge?=
 =?us-ascii?Q?WLy2+gTtS54zpwA57sGLkqJiIrJzGIchp66Xj8Hr/7LorqFiLYDExpu4/rWI?=
 =?us-ascii?Q?EgvSK0wE9c1u3YtCw52CRVD2Lmp/A0W0cAi65MyaWRTqEWHPX7/UI5JloXrf?=
 =?us-ascii?Q?m1jkSDQ4ur4Y90D4jPAg958CLbl6oUHE1BgnjLLlmE2OFERH9aiYoi4AmiQ/?=
 =?us-ascii?Q?TyhZKaiH7lm2g79Z4eXlE807d4WQXTtG/Hh6ruMinNCiXtDAx1wAwRBTfNLy?=
 =?us-ascii?Q?u6Miq/HydU/bTKUt/skeVTlh1WUO9Tu95UhJAvIetcEKQZE+k+XHm+zY4Rdl?=
 =?us-ascii?Q?slwKLOuhkw/OE432K6YNQBs=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EB715D3E58413B429F795A69D9069711@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 34eacb92-0922-4092-c4cf-08d9beefef1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2021 10:53:16.6981
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hdGsJldZ5JXsu6+8sX/GmlH7M9UAis+rOInyI3dJX7h39ZspAva8QTZRx3ShxaI22qgeadC2misNl+Zn+9ecjg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3838
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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:
> >=20
> > 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:
> > > >=20
> > > > Hi Marc (with a c),
> > > >=20
> > > > I wish the firmware for these SoCs was smart enough to be compatibl=
e
> > > > with the bindings that are in the kernel and provide a blob that th=
e
> > > > kernel could actually use. Some work has been started there and thi=
s is
> > > > work in progress. True, I don't know what other OF-based firmware s=
ome
> > > > other customers may use, but I trust it isn't a lot more advanced t=
han
> > > > what U-Boot currently has :)
> > > >=20
> > > > 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.
> > > >=20
> > > > 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
> > > >=20
> > > > | > Are we okay with the new device tree blobs breaking the old ker=
nel?
> > > > |
> > > > | From my point of view, newer device trees are not required to wor=
k on
> > > > | older kernel, this would impose an unreasonable limitation and th=
e use
> > > > | case is very limited.
> > >=20
> > > 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:
> > >=20
> > > - you don't control how updatable the firmware is
> > >=20
> > > - people may need to revert to other versions of the kernel because
> > >   the new one is broken
> > >=20
> > > - there are plenty of DT users beyond Linux, and we are not creating
> > >   bindings for Linux only.
> > >=20
> > > You may disagree with this, but for the subsystems I maintain, this i=
s
> > > the rule I intent to stick to.
> >=20
> > That's an honorable set of guiding principles, but how do you apply the=
m
> > 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.
>=20
> maz@hot-poop:~/arm-platforms$ git describe --contains 869f0ec048dc --matc=
h=3Dv\*
> v5.16-rc1~125^2~19^2~16
>=20
> 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".
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.=