[PATCH v2] of/irq: Ignore interrupt parent for nodes without interrupts

Marek Szyprowski m.szyprowski at samsung.com
Wed Nov 19 01:55:13 PST 2025


Hi Geert,

On 19.11.2025 09:53, Geert Uytterhoeven wrote:
> On Tue, 18 Nov 2025 at 20:55, Krzysztof Kozlowski <krzk at kernel.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 
arch/arm/mach-exynos/suspend.c. The question is which approach is preferred?

> --- 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)
> +                       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;
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland




More information about the linux-riscv mailing list