lkml.org 
[lkml]   [2022]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH devicetree 00/10] Do something about ls-extirq interrupt-map breakage
Date
Hello Marc,

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.
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.

I was just debugging an interesting issue with an old kernel not working
with a new DT blob, and after figuring out what the problem was (is),
I remembered this message and I'm curious what you have to say about it.

I have this DT layout:

ethernet-phy@1 {
reg = <0x1>;
interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>;
};

extirq: interrupt-controller@1ac {
compatible = "fsl,ls1021a-extirq";
<bla bla>
};

I booted the new DT blob (which has "interrupts-extended") on a kernel
where the ls-extirq driver did not exist. This had the result of
of_mdiobus_phy_device_register() -> of_irq_get() returning -EPROBE_DEFER
forever and ever. So the PHY driver in turn never probed, and Ethernet
was broken. So I had to delete the interrupts OF property to let the PHY
at least work in poll mode.

What went wrong here in your opinion?
\
 
 \ /
  Last update: 2022-03-24 18:12    [W:0.094 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site