of/irq: Ignore interrupt parent for nodes without interrupts

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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:

Quoted 11 lines · Geert Uytterhoeven

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://validation.linaro.org/scheduler/job/4252918#L409

It does seem like a plausible patch for this sort of issue though, and the bisect converges smoothly:

Quoted 20 lines · Mark Brown

Quoted 11 lines · Geert Uytterhoeven

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://validation.linaro.org/scheduler/job/4252918#L409

Quoted 2 lines

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/[email protected]/

Quoted 25 lines · Krzysztof Kozlowski

Quoted 17 lines · Mark Brown

Quoted 11 lines · Geert Uytterhoeven

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:

Quoted 4 lines

   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:

Quoted 1 line

https://lore.kernel.org/all/[email protected]/

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?

drivers/of/irq.c +2 -0

@@ -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;

Quoted 26 lines · Geert Uytterhoeven

Quoted 25 lines · Krzysztof Kozlowski

Quoted 17 lines · Mark Brown

Quoted 11 lines · Geert Uytterhoeven

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:

Quoted 4 lines

   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:

Quoted 6 lines

Quoted 1 line

https://lore.kernel.org/all/[email protected]/

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?

drivers/of/irq.c void __init of_irq_init(const struct of_device_id *matches) · line 688

Quoted 7 lines

drivers/of/irq.c +1 -0

@@ -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)

drivers/of/irq.c void __init of_irq_init(const struct of_device_id *matches) · line 692

Quoted 4 lines

drivers/of/irq.c +1 -0

+                       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;

Quoted 21 lines · Krzysztof Kozlowski

Quoted 20 lines · Mark Brown

Quoted 11 lines · Geert Uytterhoeven

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://validation.linaro.org/scheduler/job/4252918#L409

Quoted 7 lines

Quoted 2 lines

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/[email protected]/

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?

drivers/of/irq.c +2 -0

@@ -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;

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/irq.c +1 -1

index b174ec29648955c6..5cb1ca89c1d8725d 100644
@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
 		 * are the same distance away from the root irq controller.
 		 */
 		desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-		if (!desc->interrupt_parent)
+		if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
 			desc->interrupt_parent = of_irq_find_parent(np);
 		if (desc->interrupt_parent == np) {
 			of_node_put(desc->interrupt_parent);

Signature · 1 line

2.43.0

Quoted 40 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/irq.c +0 -1

index b174ec29648955c6..5cb1ca89c1d8725d 100644
@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
 		 * are the same distance away from the root irq controller.
 		 */
 		desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-		if (!desc->interrupt_parent)

Quoted 8 lines

drivers/of/irq.c +1 -0

+		if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
 			desc->interrupt_parent = of_irq_find_parent(np);
 		if (desc->interrupt_parent == np) {
 			of_node_put(desc->interrupt_parent);

Signature · 1 line

2.43.0

This change broke irq-ls-extirq and commit 6ba51b7b34ca ("of/irq:
Handle explicit interrupt parent") does not help with the issue.

This is how the DT node in lx2160a.dtsi looks like:

	extirq: interrupt-controller@14 {
		compatible = "fsl,lx2160a-extirq", "fsl,ls1088a-extirq";
		#interrupt-cells = <2>;
		#address-cells = <0>;
		interrupt-controller;
		reg = <0x14 4>;
		interrupt-map =
			<0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
			<1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
			<2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
			<3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
			<4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
			<5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
			<6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
			<7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
			<8 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
			<9 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
			<10 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
			<11 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
		interrupt-map-mask = <0xf 0x0>;
	};

with the following being in the root node:

	interrupt-parent = <&gic>;

Ioana

Quoted 45 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/irq.c +1 -2

index b174ec29648955c6..5cb1ca89c1d8725d 100644
@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
               * are the same distance away from the root irq controller.
               */
              desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-             if (!desc->interrupt_parent)
+             if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
                      desc->interrupt_parent = of_irq_find_parent(np);
              if (desc->interrupt_parent == np) {
                      of_node_put(desc->interrupt_parent);
--

Quoted 3 lines

2.43.0

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

This is how the DT node in lx2160a.dtsi looks like:

Quoted 38 lines · Ioana Ciornei

Quoted 25 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

drivers/of/irq.c void __init of_irq_init(const struct of_device_id *matches) · line 619

Quoted 8 lines

drivers/of/irq.c +1 -1

@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
               * are the same distance away from the root irq controller.
               */
              desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-             if (!desc->interrupt_parent)
+             if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
                      desc->interrupt_parent = of_irq_find_parent(np);
              if (desc->interrupt_parent == np) {
                      of_node_put(desc->interrupt_parent);

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

Quoted 1 line

This is how the DT node in lx2160a.dtsi looks like:

ls-extirq strikes again!

I think something like this should fix it:

drivers/of/irq.c +0 -0

index 2271110b5f7c..c06c74aef801 100644

drivers/of/irq.c +0 -0

                        desc->interrupt_parent = of_irq_find_parent(np);
                else if (!desc->interrupt_parent)
                        desc->interrupt_parent = of_parse_phandle(np, "interrupt-parent", 0);

But really, at some point it should be converted to a proper driver as there's no reason extirq needs to be initialized early.

Hi Rob,

Thanks, I was just looking into this...

Quoted 54 lines · Rob Herring

Quoted 38 lines · Ioana Ciornei

Quoted 25 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

drivers/of/irq.c void __init of_irq_init(const struct of_device_id *matches) · line 619

Quoted 8 lines

drivers/of/irq.c +1 -1

@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
               * are the same distance away from the root irq controller.
               */
              desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-             if (!desc->interrupt_parent)
+             if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
                      desc->interrupt_parent = of_irq_find_parent(np);
              if (desc->interrupt_parent == np) {
                      of_node_put(desc->interrupt_parent);

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

Quoted 1 line

This is how the DT node in lx2160a.dtsi looks like:

ls-extirq strikes again!

I think something like this should fix it:

drivers/of/irq.c +0 -1

index 2271110b5f7c..c06c74aef801 100644
@@ -593,7 +593,8 @@ void __init of_irq_init(const struct of_device_id *matches)
                 * are the same distance away from the root irq controller.
                 */
                desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-               if (!desc->interrupt_parent && of_property_present(np, "interrupts"))

drivers/of/irq.c void __init of_irq_init(const struct of_device_id *matches) · line 597

Quoted 2 lines

drivers/of/irq.c +2 -0

+               if (!desc->interrupt_parent &&
+                   (of_property_present(np, "interrupts") || of_property_present(np, "interrupt-map"))

That should indeed restore the previous behavior, and find again "interrupt-parent = &gic" in the root node. However, wouldn't it be more correct to follow the approach used for interrupts-extended, and use the first interrupt parent from the interrupt-map (which is coincidentally &gic, too)?

Quoted 54 lines · Ioana Ciornei

Quoted 45 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/irq.c +1 -2

index b174ec29648955c6..5cb1ca89c1d8725d 100644
@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
               * are the same distance away from the root irq controller.
               */
              desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-             if (!desc->interrupt_parent)
+             if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
                      desc->interrupt_parent = of_irq_find_parent(np);
              if (desc->interrupt_parent == np) {
                      of_node_put(desc->interrupt_parent);
--

Quoted 3 lines

2.43.0

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

Quoted 1 line

This is how the DT node in lx2160a.dtsi looks like:

ls-extirq strikes again!

I think something like this should fix it:

drivers/of/irq.c +2 -1

index 2271110b5f7c..c06c74aef801 100644
@@ -593,7 +593,8 @@ void __init of_irq_init(const struct of_device_id *matches)
                 * are the same distance away from the root irq controller.
                 */
                desc->interrupt_parent = of_parse_phandle(np,
 "interrupts-extended", 0);
-               if (!desc->interrupt_parent && of_property_present(np,
 "interrupts"))
+               if (!desc->interrupt_parent &&
+                   (of_property_present(np, "interrupts") ||
 of_property_present(np, "interrupt-map"))

                        desc->interrupt_parent = of_irq_find_parent(np);
                else if (!desc->interrupt_parent)
                        desc->interrupt_parent = of_parse_phandle(np,

"interrupt-parent", 0);

But really, at some point it should be converted to a proper driver as there's no reason extirq needs to be initialized early.

Quoted 78 lines · Rob Herring

Quoted 54 lines · Ioana Ciornei

Quoted 45 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/irq.c +1 -2

index b174ec29648955c6..5cb1ca89c1d8725d 100644
@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
               * are the same distance away from the root irq controller.
               */
              desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-             if (!desc->interrupt_parent)
+             if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
                      desc->interrupt_parent = of_irq_find_parent(np);
              if (desc->interrupt_parent == np) {
                      of_node_put(desc->interrupt_parent);
--

Quoted 3 lines

2.43.0

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

Quoted 1 line

This is how the DT node in lx2160a.dtsi looks like:

ls-extirq strikes again!

I think something like this should fix it:

drivers/of/irq.c +2 -1

index 2271110b5f7c..c06c74aef801 100644
@@ -593,7 +593,8 @@ void __init of_irq_init(const struct of_device_id *matches)
                 * are the same distance away from the root irq controller.
                 */
                desc->interrupt_parent = of_parse_phandle(np,
 "interrupts-extended", 0);
-               if (!desc->interrupt_parent && of_property_present(np,
 "interrupts"))
+               if (!desc->interrupt_parent &&
+                   (of_property_present(np, "interrupts") ||
 of_property_present(np, "interrupt-map"))

                        desc->interrupt_parent = of_irq_find_parent(np);
                else if (!desc->interrupt_parent)
                        desc->interrupt_parent = of_parse_phandle(np,

Quoted 6 lines

"interrupt-parent", 0);

But really, at some point it should be converted to a proper driver as there's no reason extirq needs to be initialized early.

I just tried converting ls-extirq to a proper platform driver and it's pretty straightforward. The problem is getting that driver to probe on the ls-extirq dt node since of_platform_populate() is not called on its parent node.

I would avoid changing the DT and adding a "simple-bus" compatible to the parent nodes. The other option is to add another simple driver which just calls of_platform_populate() for all compatible strings defined in fsl,layerscape-scfg.yaml.

Quoted 92 lines · Ioana Ciornei

Quoted 78 lines · Rob Herring

Quoted 54 lines · Ioana Ciornei

Quoted 45 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Signed-off-by Geert Uytterhoeven <[email protected]>

v2:
- Split off from series "[PATCH/RFC 0/2] of/irq: Fix root interrupt controller handling"[1] to relax dependencies,
- Drop RFC.

[1] https://lore.kernel.org/all/[email protected]

---
 drivers/of/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/irq.c +1 -2

index b174ec29648955c6..5cb1ca89c1d8725d 100644
@@ -613,7 +613,7 @@ void __init of_irq_init(const struct of_device_id *matches)
               * are the same distance away from the root irq controller.
               */
              desc->interrupt_parent = of_parse_phandle(np, "interrupts-extended", 0);
-             if (!desc->interrupt_parent)
+             if (!desc->interrupt_parent && of_property_present(np, "interrupts"))
                      desc->interrupt_parent = of_irq_find_parent(np);
              if (desc->interrupt_parent == np) {
                      of_node_put(desc->interrupt_parent);
--

Quoted 3 lines

2.43.0

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

Quoted 1 line

This is how the DT node in lx2160a.dtsi looks like:

ls-extirq strikes again!

I think something like this should fix it:

drivers/of/irq.c +2 -1

index 2271110b5f7c..c06c74aef801 100644
@@ -593,7 +593,8 @@ void __init of_irq_init(const struct of_device_id *matches)
                 * are the same distance away from the root irq controller.
                 */
                desc->interrupt_parent = of_parse_phandle(np,
 "interrupts-extended", 0);
-               if (!desc->interrupt_parent && of_property_present(np,
 "interrupts"))
+               if (!desc->interrupt_parent &&
+                   (of_property_present(np, "interrupts") ||
 of_property_present(np, "interrupt-map"))

                        desc->interrupt_parent = of_irq_find_parent(np);
                else if (!desc->interrupt_parent)
                        desc->interrupt_parent = of_parse_phandle(np,

Quoted 6 lines

"interrupt-parent", 0);

But really, at some point it should be converted to a proper driver as there's no reason extirq needs to be initialized early.

I just tried converting ls-extirq to a proper platform driver and it's pretty straightforward. The problem is getting that driver to probe on the ls-extirq dt node since of_platform_populate() is not called on its parent node.

Quoted 4 lines

I would avoid changing the DT and adding a "simple-bus" compatible to the parent nodes. The other option is to add another simple driver which just calls of_platform_populate() for all compatible strings defined in fsl,layerscape-scfg.yaml.

The simplest solution might be adding 'syscon' to the default match list for of_platform_populate(). That's kind of a big hammer though and could break something. Not sure, but I'm willing to stick that in linux-next and see.

Another option is hijack the simple-pm-bus driver which already does just what you said.

Quoted 39 lines · Rob Herring

Quoted 33 lines · Ioana Ciornei

Quoted 22 lines · Rob Herring

Quoted 21 lines · Ioana Ciornei

Quoted 20 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

Signed-off-by Geert Uytterhoeven <[email protected]>

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

I just tried converting ls-extirq to a proper platform driver and it's pretty straightforward. The problem is getting that driver to probe on the ls-extirq dt node since of_platform_populate() is not called on its parent node.

Quoted 4 lines

I would avoid changing the DT and adding a "simple-bus" compatible to the parent nodes. The other option is to add another simple driver which just calls of_platform_populate() for all compatible strings defined in fsl,layerscape-scfg.yaml.

Quoted 7 lines

The simplest solution might be adding 'syscon' to the default match list for of_platform_populate(). That's kind of a big hammer though and could break something. Not sure, but I'm willing to stick that in linux-next and see.

Another option is hijack the simple-pm-bus driver which already does just what you said.

I would prefer the second option since that doesn't impact other platforms.

Geert, since you are the module author, are you ok with the following diff?

drivers/bus/simple-pm-bus.c +0 -0

@@ -142,6 +142,12 @@ static const struct of_device_id simple_pm_bus_of_match[] = {
        { .compatible = "simple-mfd",   .data = ONLY_BUS },
        { .compatible = "isa",          .data = ONLY_BUS },

Hi Ionana,

Quoted 59 lines · Ioana Ciornei

Quoted 39 lines · Rob Herring

Quoted 33 lines · Ioana Ciornei

Quoted 22 lines · Rob Herring

Quoted 21 lines · Ioana Ciornei

Quoted 20 lines · Geert Uytterhoeven

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:

OF: of_irq_init: children remain, but no parents Kernel panic - not syncing: No interrupt controller found.

Commit e91033621d56e055 ("of/irq: Use interrupts-extended to find parent") already fixed a first part, by checking for the presence of an interrupts-extended property. Fix the second part by only calling of_irq_find_parent() when an interrupts property is present.

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

Signed-off-by Geert Uytterhoeven <[email protected]>

This change irq-ls-extirq and commit 6ba51b7b34ca ("of/irq: Handle explicit interrupt parent") does not help with the issue.

I just tried converting ls-extirq to a proper platform driver and it's pretty straightforward. The problem is getting that driver to probe on the ls-extirq dt node since of_platform_populate() is not called on its parent node.

Quoted 4 lines

I would avoid changing the DT and adding a "simple-bus" compatible to the parent nodes. The other option is to add another simple driver which just calls of_platform_populate() for all compatible strings defined in fsl,layerscape-scfg.yaml.

Quoted 7 lines

The simplest solution might be adding 'syscon' to the default match list for of_platform_populate(). That's kind of a big hammer though and could break something. Not sure, but I'm willing to stick that in linux-next and see.

Another option is hijack the simple-pm-bus driver which already does just what you said.

I would prefer the second option since that doesn't impact other platforms.

Geert, since you are the module author, are you ok with the following diff?

drivers/bus/simple-pm-bus.c +0 -0

@@ -142,6 +142,12 @@ static const struct of_device_id simple_pm_bus_of_match[] = {
        { .compatible = "simple-mfd",   .data = ONLY_BUS },
        { .compatible = "isa",          .data = ONLY_BUS },

drivers/bus/simple-pm-bus.c static const struct of_device_id simple_pm_bus_of_match[] = { · line 153

Quoted 10 lines

drivers/bus/simple-pm-bus.c +6 -0

        { .compatible = "arm,amba-bus", .data = ONLY_BUS },
+       { .compatible = "fsl,ls1021a-scfg", },
+       { .compatible = "fsl,ls1043a-scfg", },
+       { .compatible = "fsl,ls1046a-scfg", },
+       { .compatible = "fsl,ls1088a-isc", },
+       { .compatible = "fsl,ls2080a-isc", },
+       { .compatible = "fsl,lx2160a-isc", },
        { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match);

Fine for me.

Alternatively, these could be added to the match_table[] in drivers/of/platform.c:of_platform_default_populate()?