On Thu, 24 Mar 2022 19:09:05 +0000, Vladimir Oltean <vladimir.oltean@xxxxxxx> 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.
