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: Thu, 24 Mar 2022 20:14:30 +0000 [thread overview] Message-ID: <87ee2rxg49.wl-maz@kernel.org> (raw) In-Reply-To: <20220324190904.boo2izjc3mym2wkh@skbuf> On Thu, 24 Mar 2022 19:09:05 +0000, Vladimir Oltean <vladimir.oltean@nxp.com> wrote: > > On Thu, Mar 24, 2022 at 06:06:51PM +0000, Marc Zyngier wrote: > > > I was just raising this as what I thought would be a simple and > > > non-controversial counter example to your remark "If you change something, > > > you *must* guarantee forward *and* backward compatibility." > > > > If you change something *in the binding*, which was implicit in the > > context, and makes no sense out of context. > > > > > Practically speaking, what has happened is that the board DT appeared in > > > kernel N, the ls-extirq driver in kernel N+1, and the DT was updated to > > > enable PHY interrupts in kernel N+2. That DT update practically broke > > > kernel N from running correctly on DTs taken from kernel N+2 onwards. > > > This is the observable behavior, we can find as many justifications for > > > it as we wish. > > > > Well, you can also argue that the DT was broken at N and N+1 for not > > describing the HW correctly and completely. No binding has changed > > here. Your DT was incomplete, and someone fixed it for you. > > > > We can argue this things forever and a half. I've laid down the ground > > rules for the stuff I maintain. If you're not happy with this, you can > > fix it by either removing the NXP hardware from the tree, or taking > > over from me as the irqchip maintainer. I'd be perfectly happy with > > any (and even more, with both) of these outcomes. > > Ok, my intention wasn't to inflame you even though the way in which I > presented the problem might have suggested otherwise. > > With my developer hat I still don't agree with you even with the > additional clarification you've made that you were referring only to > bindings and not to any and all DT changes. The reason being that the DT > blob is a whole, and it doesn't matter if there's a regression because > of a binding change or something else, you still need to be prepared to > update it, sometimes in lockstep with the kernel, like it or not. <rant> No. This doesn't happen on systems that ship the DT as part of their firmware, and this doesn't happen with ACPI either. This only happens on platform that are maintained like the NXP, Marvell, and other similar platforms that are being used as a job security tool by doing piecemeal enablement. Properly maintained systems have had the same DT for years. Features have been added over time, yet without breaking compatibility in either direction. Yes, it requires some effort and planning. And even quirks at times. Yet they don't break. Amusingly, some of these better supported platforms do not have their DT in the kernel tree. Synquacer, for example. Keeping the DTs in the kernel tree has been one of the worse decision we have ever made. It has simply moved the board files of old to a different place, under the guise of separating description and code. In practice, it abstracted nothing at all, only made it more complicated because people are treating DT as an integral part of the kernel code base, which it really shouldn't be. </rant> > But as a user, I just wanted to get an opinion from you what can we do > to deal better with this situation: optional interrupt provided by > device with missing driver, which of_irq_get() doesn't seem to understand. > There are more angles to this than just "new DT with old kernel". It can > also be new kernel, but ls-extirq driver disabled, and I still see that > as a kernel <-> DT compatibility concern. If you're missing a driver, that's a user error. Or rather, a platform maintainer error for not establishing the correct dependencies. This has nothing to do with the DT. As for optional interrupts, that has nothing to do with the DT either, but with the kernel code that requests it. If you think the kernel should do better, you can always post a patch. And I'm done on that subject. 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: Thu, 24 Mar 2022 20:14:30 +0000 [thread overview] Message-ID: <87ee2rxg49.wl-maz@kernel.org> (raw) In-Reply-To: <20220324190904.boo2izjc3mym2wkh@skbuf> On Thu, 24 Mar 2022 19:09:05 +0000, Vladimir Oltean <vladimir.oltean@nxp.com> wrote: > > On Thu, Mar 24, 2022 at 06:06:51PM +0000, Marc Zyngier wrote: > > > I was just raising this as what I thought would be a simple and > > > non-controversial counter example to your remark "If you change something, > > > you *must* guarantee forward *and* backward compatibility." > > > > If you change something *in the binding*, which was implicit in the > > context, and makes no sense out of context. > > > > > Practically speaking, what has happened is that the board DT appeared in > > > kernel N, the ls-extirq driver in kernel N+1, and the DT was updated to > > > enable PHY interrupts in kernel N+2. That DT update practically broke > > > kernel N from running correctly on DTs taken from kernel N+2 onwards. > > > This is the observable behavior, we can find as many justifications for > > > it as we wish. > > > > Well, you can also argue that the DT was broken at N and N+1 for not > > describing the HW correctly and completely. No binding has changed > > here. Your DT was incomplete, and someone fixed it for you. > > > > We can argue this things forever and a half. I've laid down the ground > > rules for the stuff I maintain. If you're not happy with this, you can > > fix it by either removing the NXP hardware from the tree, or taking > > over from me as the irqchip maintainer. I'd be perfectly happy with > > any (and even more, with both) of these outcomes. > > Ok, my intention wasn't to inflame you even though the way in which I > presented the problem might have suggested otherwise. > > With my developer hat I still don't agree with you even with the > additional clarification you've made that you were referring only to > bindings and not to any and all DT changes. The reason being that the DT > blob is a whole, and it doesn't matter if there's a regression because > of a binding change or something else, you still need to be prepared to > update it, sometimes in lockstep with the kernel, like it or not. <rant> No. This doesn't happen on systems that ship the DT as part of their firmware, and this doesn't happen with ACPI either. This only happens on platform that are maintained like the NXP, Marvell, and other similar platforms that are being used as a job security tool by doing piecemeal enablement. Properly maintained systems have had the same DT for years. Features have been added over time, yet without breaking compatibility in either direction. Yes, it requires some effort and planning. And even quirks at times. Yet they don't break. Amusingly, some of these better supported platforms do not have their DT in the kernel tree. Synquacer, for example. Keeping the DTs in the kernel tree has been one of the worse decision we have ever made. It has simply moved the board files of old to a different place, under the guise of separating description and code. In practice, it abstracted nothing at all, only made it more complicated because people are treating DT as an integral part of the kernel code base, which it really shouldn't be. </rant> > But as a user, I just wanted to get an opinion from you what can we do > to deal better with this situation: optional interrupt provided by > device with missing driver, which of_irq_get() doesn't seem to understand. > There are more angles to this than just "new DT with old kernel". It can > also be new kernel, but ls-extirq driver disabled, and I still see that > as a kernel <-> DT compatibility concern. If you're missing a driver, that's a user error. Or rather, a platform maintainer error for not establishing the correct dependencies. This has nothing to do with the DT. As for optional interrupts, that has nothing to do with the DT either, but with the kernel code that requests it. If you think the kernel should do better, you can always post a patch. And I'm done on that subject. 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:[~2022-03-24 20:14 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 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 [this message] 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=87ee2rxg49.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.