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 11:11:25 +0000 [thread overview] Message-ID: <877dc7jvaa.wl-maz@kernel.org> (raw) In-Reply-To: <20211214105316.aibjmwdhg7a5wwlj@skbuf> 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.
WARNING: multiple messages have this Message-ID (diff)
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 11:11:25 +0000 [thread overview] Message-ID: <877dc7jvaa.wl-maz@kernel.org> (raw) In-Reply-To: <20211214105316.aibjmwdhg7a5wwlj@skbuf> 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-14 11:11 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-14 1:37 [RFC PATCH devicetree 00/10] Do something about ls-extirq interrupt-map breakage Vladimir Oltean 2021-12-14 1:37 ` Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 01/10] irqchip/ls-extirq: rename "interrupt-map" OF property to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 01/10] irqchip/ls-extirq: rename "interrupt-map" OF property to "fsl, extirq-map" Vladimir Oltean 2021-12-14 8:46 ` [RFC PATCH devicetree 01/10] irqchip/ls-extirq: rename "interrupt-map" OF property to "fsl,extirq-map" Kurt Kanzenbach 2021-12-14 8:46 ` Kurt Kanzenbach 2021-12-14 15:07 ` Rob Herring 2021-12-14 15:07 ` Rob Herring 2021-12-14 1:37 ` [RFC PATCH devicetree 02/10] Revert "arm64: dts: freescale: Fix 'interrupt-map' parent address cells" Vladimir Oltean 2021-12-14 1:37 ` Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 03/10] dt-bindings: ls-extirq: replace "interrupt-map" documentation with "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 03/10] dt-bindings: ls-extirq: replace "interrupt-map" documentation with "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 04/10] arm64: dts: ls1043a: rename the "interrupt-map" of the extirq node to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 04/10] arm64: dts: ls1043a: rename the "interrupt-map" of the extirq node to "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 05/10] arm64: dts: ls1046a: rename the "interrupt-map" of the extirq node to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 05/10] arm64: dts: ls1046a: rename the "interrupt-map" of the extirq node to "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 06/10] arm64: dts: ls1088a: rename the "interrupt-map" of the extirq node to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 06/10] arm64: dts: ls1088a: rename the "interrupt-map" of the extirq node to "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 07/10] arm64: dts: ls208xa: rename the "interrupt-map" of the extirq node to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 07/10] arm64: dts: ls208xa: rename the "interrupt-map" of the extirq node to "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 08/10] arm64: dts: lx2160a: rename the "interrupt-map" of the extirq node to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 08/10] arm64: dts: lx2160a: rename the "interrupt-map" of the extirq node to "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 09/10] ARM: dts: ls1021a: rename the "interrupt-map" of the extirq node to "fsl,extirq-map" Vladimir Oltean 2021-12-14 1:37 ` [RFC PATCH devicetree 09/10] ARM: dts: ls1021a: rename the "interrupt-map" of the extirq node to "fsl, extirq-map" Vladimir Oltean 2021-12-14 1:38 ` [RFC PATCH devicetree 10/10] dt-bindings: ls-extirq: add a YAML schema for the validator Vladimir Oltean 2021-12-14 1:38 ` Vladimir Oltean 2021-12-14 15:21 ` Rob Herring 2021-12-14 15:21 ` Rob Herring 2021-12-14 8:51 ` [RFC PATCH devicetree 00/10] Do something about ls-extirq interrupt-map breakage Marc Zyngier 2021-12-14 8:51 ` Marc Zyngier 2021-12-14 9:58 ` Vladimir Oltean 2021-12-14 9:58 ` Vladimir Oltean 2021-12-14 10:20 ` Marc Zyngier 2021-12-14 10:20 ` Marc Zyngier 2021-12-14 10:30 ` Vladimir Oltean 2021-12-14 10:30 ` Vladimir Oltean 2021-12-14 10:39 ` Marc Zyngier 2021-12-14 10:39 ` Marc Zyngier 2021-12-14 10:53 ` Vladimir Oltean 2021-12-14 10:53 ` Vladimir Oltean 2021-12-14 11:11 ` Marc Zyngier [this message] 2021-12-14 11:11 ` Marc Zyngier 2022-03-24 17:10 ` Vladimir Oltean 2022-03-24 17:10 ` Vladimir Oltean 2022-03-24 17:21 ` Marc Zyngier 2022-03-24 17:21 ` Marc Zyngier 2022-03-24 17:34 ` Vladimir Oltean 2022-03-24 17:34 ` Vladimir Oltean 2022-03-24 18:06 ` Marc Zyngier 2022-03-24 18:06 ` Marc Zyngier 2022-03-24 19:09 ` Vladimir Oltean 2022-03-24 19:09 ` Vladimir Oltean 2022-03-24 20:14 ` Marc Zyngier 2022-03-24 20:14 ` Marc Zyngier 2022-03-25 10:34 ` Robin Murphy 2022-03-25 10:34 ` Robin Murphy 2022-03-25 17:54 ` Vladimir Oltean 2022-03-25 17:54 ` Vladimir Oltean
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=877dc7jvaa.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=biwen.li@nxp.com \ --cc=devicetree@vger.kernel.org \ --cc=kurt@linutronix.de \ --cc=leoyang.li@nxp.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@rasmusvillemoes.dk \ --cc=robh+dt@kernel.org \ --cc=shawnguo@kernel.org \ --cc=vladimir.oltean@nxp.com \ --cc=zhiqiang.hou@nxp.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.