lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 24 Mar 2022 17:10:42 +0000 From: Vladimir Oltean <vladimir.oltean@....com> To: Marc Zyngier <maz@...nel.org> CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Rob Herring <robh+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>, Leo Li <leoyang.li@....com>, Biwen Li <biwen.li@....com>, "Z.Q. Hou" <zhiqiang.hou@....com>, Kurt Kanzenbach <kurt@...utronix.de>, Rasmus Villemoes <linux@...musvillemoes.dk> Subject: Re: [RFC PATCH devicetree 00/10] Do something about ls-extirq interrupt-map breakage 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@....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?
Powered by blists - more mailing lists