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

[Marc Zyngier]

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