linux-kernel - Re: [PATCH v2] of/irq: Ignore interrupt parent for nodes without interrupts

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdU5ixRpE+yPbggBG91+516YD+ARkaCLN-gM8bQLvtqrYg@mail.gmail.com>
Date: Wed, 19 Nov 2025 11:59:08 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>, 
	Saravana Kannan <saravanak@...gle.com>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Paul Walmsley <pjw@...nel.org>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	Alexandre Ghiti <alex@...ti.fr>, Samuel Holland <samuel@...lland.org>, Marc Zyngier <maz@...nel.org>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>, 
	Magnus Damm <magnus.damm@...il.com>, devicetree@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, 
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>
Subject: Re: [PATCH v2] of/irq: Ignore interrupt parent for nodes without interrupts

Hi Marek,

On Wed, 19 Nov 2025 at 10:55, Marek Szyprowski <m.szyprowski@...sung.com> wrote:
> On 19.11.2025 09:53, Geert Uytterhoeven wrote:
> > On Tue, 18 Nov 2025 at 20:55, Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >> On 18/11/2025 20:34, Mark Brown wrote:
> >>> On Fri, Nov 14, 2025 at 11:47:54AM +0100, Geert Uytterhoeven wrote:
> >>>> The Devicetree Specification states:
> >>>>
> >>>>      The root of the interrupt tree is determined when traversal of the
> >>>>      interrupt tree reaches an interrupt controller node without an
> >>>>      interrupts property and thus no explicit interrupt parent.
> >>>>
> >>>> However, of_irq_init() gratuitously assumes that a node without
> >>>> interrupts has an actual interrupt parent if it finds an
> >>>> interrupt-parent property higher up in the device tree.  Hence when such
> >>>> a property is present (e.g. in the root node), the root interrupt
> >>>> controller may not be detected as such, causing a panic:
> >>> I'm seeing a boot regression on the TI x15 platform in -next which
> >>> bisects to this patch in -next, unfortunately even with earlycon (though
> >>> just earlycon, I don't know the platform specific runes) the board just
> >>> dies with no output:
> >>>
> >>>    https://protect2.fireeye.com/v1/url?k=7efe2b91-216202bb-7effa0de-000babe598f7-79b85fd5422be185&q=1&e=a2b4aea0-c947-472b-ae80-9160750f84a2&u=https%3A%2F%2Fvalidation.linaro.org%2Fscheduler%2Fjob%2F4252918%23L409
> >>>
> >>> It does seem like a plausible patch for this sort of issue though, and
> >>> the bisect converges smoothly:
> >> All Samsung platforms fail as well. I was waiting with bisection but
> >> Marek was as usually very fast:
> >>
> >> https://lore.kernel.org/all/20251118115037.1866871-1-m.szyprowski@samsung.com/
> > Yeah, the various ti,omap[45]-wugen-mpu nodes have interrupt-parent
> > properties, but no interrupts{-extended} properties.
> >
> > Does the following (whitespace-damaged) patch, to restore finding an
> > explicit interrupt-parent, fix the issue?
>
> This also fixes Exynos case without any need for the changes in

Thanks for testing!

> arch/arm/mach-exynos/suspend.c. The question is which approach is preferred?

It looks like several other drivers are affected.  So I think it
makes sense to handle the presence of an explicit "interrupt-parent"
in an interrupt-less interrupt controller node in the core, instead
of in each affected driver.

> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -685,6 +685,8 @@ void __init of_irq_init(const struct of_device_id *matches)
> >                  desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
> >                  if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
> >                          desc->interrupt_parent = of_irq_find_parent(np);
> > +               if (!desc->interrupt_parent)

Or "else if (!desc->interrupt_parent)", to avoid repeating part of
of_irq_find_parent() when an "interrupts" property is present?

> > +                       desc->interrupt_parent = of_parse_phandle(np, "interrupt-parent", 0);
> >                  if (desc->interrupt_parent == np) {
> >                          of_node_put(desc->interrupt_parent);
> >                          desc->interrupt_parent = NULL;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds