[PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[Ioana Ciornei]

Starting with commit 1b1f04d8271e ("of/irq: Ignore interrupt parent for
nodes without interrupts"), the ls-extirq stopped working. This is
because ls-extirq, being one of the interrupt-map property abusers,
does not pass the dt checks added by the referenced commit, making it
unable to determine its interrupt parent.

Instead of reverting the referenced commit, convert the ls-extirq to a
platform driver so that we avoid completely the irqchip_init() ->
of_irq_init() code path. This is what patch 1/2 does.

Patch 2/2 makes the parent dt nodes of ls-extirq to get probed by the
simple-pm-bus driver, for the single goal of it running
of_platform_populate(). Without this patch, the simple-pm-bus will not
get to probe on the ls-extirq nodes.

Alternative fixup routes were discussed in the following thread.
https://lore.kernel.org/all/CAL_JsqJ4q2=UJbuhfbvsbr2T+SRGXsPSXCLk6iXZid_qwYrN4g@mail.gmail.com/

Changes in v2:
- Use builtin_platform_driver since the driver cannot be built as a
  module

Ioana Ciornei (2):
  irqchip/ls-extirq: convert to a platform driver
  bus: simple-pm-bus: probe the Layerscape SCFG node

 drivers/bus/simple-pm-bus.c     |  6 ++++++
 drivers/irqchip/irq-ls-extirq.c | 32 +++++++++++++++++++++++++++-----
 2 files changed, 33 insertions(+), 5 deletions(-)

-- 
2.25.1

[PATCH v2 1/2] irqchip/ls-extirq: convert to a platform driver

[Ioana Ciornei]

Since there is no need for ls-extirq to be initialized early, convert it
to a proper platform driver. Instead of using IRQCHIP_DECLARE, add an
of_device_id array with the same compatible strings as before. Also
change the prototype and name of the probe function and adjust it to a
platform_device structure.

With this change we also have the added advantage of avoiding the
irqchip_init() -> of_irq_init() code path which imposes dt checks that
the ls-extirq does not comply with because of its improper use of the
interrupt-map property.

Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v2:
- use builtin_platform_driver

 drivers/irqchip/irq-ls-extirq.c | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-ls-extirq.c b/drivers/irqchip/irq-ls-extirq.c
index 50a7b38381b9..23b3b6f84650 100644
--- a/drivers/irqchip/irq-ls-extirq.c
+++ b/drivers/irqchip/irq-ls-extirq.c
@@ -168,13 +168,21 @@ ls_extirq_parse_map(struct ls_extirq_data *priv, struct device_node *node)
 	return 0;
 }
 
-static int __init
-ls_extirq_of_init(struct device_node *node, struct device_node *parent)
+static int ls_extirq_probe(struct platform_device *pdev)
 {
 	struct irq_domain *domain, *parent_domain;
+	struct device_node *node, *parent;
+	struct device *dev = &pdev->dev;
 	struct ls_extirq_data *priv;
 	int ret;
 
+	node = dev->of_node;
+	parent = of_irq_find_parent(node);
+	if (!parent) {
+		dev_err(dev, "Failed to get IRQ parent node\n");
+		return -ENODEV;
+	}
+
 	parent_domain = irq_find_host(parent);
 	if (!parent_domain) {
 		pr_err("Cannot find parent domain\n");
@@ -227,6 +235,20 @@ ls_extirq_of_init(struct device_node *node, struct device_node *parent)
 	return ret;
 }
 
-IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq", ls_extirq_of_init);
-IRQCHIP_DECLARE(ls1043a_extirq, "fsl,ls1043a-extirq", ls_extirq_of_init);
-IRQCHIP_DECLARE(ls1088a_extirq, "fsl,ls1088a-extirq", ls_extirq_of_init);
+static const struct of_device_id ls_extirq_dt_ids[] = {
+	{ .compatible = "fsl,ls1021a-extirq" },
+	{ .compatible = "fsl,ls1043a-extirq" },
+	{ .compatible = "fsl,ls1088a-extirq" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, ls_extirq_dt_ids);
+
+static struct platform_driver ls_extirq_driver = {
+	.probe = ls_extirq_probe,
+	.driver = {
+		.name = "ls-extirq",
+		.of_match_table = ls_extirq_dt_ids,
+	}
+};
+
+builtin_platform_driver(ls_extirq_driver);
-- 
2.25.1

Re: [PATCH v2 1/2] irqchip/ls-extirq: convert to a platform driver

[Thomas Gleixner]

On Fri, Dec 05 2025 at 17:57, Ioana Ciornei wrote:
> Since there is no need for ls-extirq to be initialized early, convert it
> to a proper platform driver. Instead of using IRQCHIP_DECLARE, add an
> of_device_id array with the same compatible strings as before. Also
> change the prototype and name of the probe function and adjust it to a
> platform_device structure.
>
> With this change we also have the added advantage of avoiding the
> irqchip_init() -> of_irq_init() code path which imposes dt checks that
> the ls-extirq does not comply with because of its improper use of the
> interrupt-map property.
>
> Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")

I'm not seeing how that Fixes tag is related. Your changelog clearly
lacks a proper explanation.

Aside of that there is this series:

      https://lore.kernel.org/20251201105144.539450-1-alexander.stein@ew.tq-group.com

which is way more complete and cleans up the thing nicely instead of
just converting it to a platform driver with minimal effort.

Thanks,

        tglx

Re: [PATCH v2 1/2] irqchip/ls-extirq: convert to a platform driver

[Alexander Stein]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

Hi,

thanks for bringing this to me.

Am Freitag, 12. Dezember 2025, 02:24:19 CET schrieb Thomas Gleixner:
> On Fri, Dec 05 2025 at 17:57, Ioana Ciornei wrote:
> > Since there is no need for ls-extirq to be initialized early, convert it
> > to a proper platform driver. Instead of using IRQCHIP_DECLARE, add an
> > of_device_id array with the same compatible strings as before. Also
> > change the prototype and name of the probe function and adjust it to a
> > platform_device structure.
> >
> > With this change we also have the added advantage of avoiding the
> > irqchip_init() -> of_irq_init() code path which imposes dt checks that
> > the ls-extirq does not comply with because of its improper use of the
> > interrupt-map property.
> >
> > Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")
> 
> I'm not seeing how that Fixes tag is related. Your changelog clearly
> lacks a proper explanation.
> 
> Aside of that there is this series:
> 
>       https://lore.kernel.org/20251201105144.539450-1-alexander.stein@ew.tq-group.com
> 
> which is way more complete and cleans up the thing nicely instead of
> just converting it to a platform driver with minimal effort.

There is still one open question: How to deal with the scfg/isc nodes?
Use patch 2/2 of this series to make them additional pm-busses or move the
ls-ext-irq nodes outside of it?

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/2] irqchip/ls-extirq: convert to a platform driver

[Ioana Ciornei]

On Fri, Dec 12, 2025 at 10:51:12AM +0100, Alexander Stein wrote:
> Hi,
> 
> thanks for bringing this to me.
> 
> Am Freitag, 12. Dezember 2025, 02:24:19 CET schrieb Thomas Gleixner:
> > On Fri, Dec 05 2025 at 17:57, Ioana Ciornei wrote:
> > > Since there is no need for ls-extirq to be initialized early, convert it
> > > to a proper platform driver. Instead of using IRQCHIP_DECLARE, add an
> > > of_device_id array with the same compatible strings as before. Also
> > > change the prototype and name of the probe function and adjust it to a
> > > platform_device structure.
> > >
> > > With this change we also have the added advantage of avoiding the
> > > irqchip_init() -> of_irq_init() code path which imposes dt checks that
> > > the ls-extirq does not comply with because of its improper use of the
> > > interrupt-map property.
> > >
> > > Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")
> > 
> > I'm not seeing how that Fixes tag is related. Your changelog clearly
> > lacks a proper explanation.
> > 
> > Aside of that there is this series:
> > 
> >       https://lore.kernel.org/20251201105144.539450-1-alexander.stein@ew.tq-group.com
> > 
> > which is way more complete and cleans up the thing nicely instead of
> > just converting it to a platform driver with minimal effort.
> 
> There is still one open question: How to deal with the scfg/isc nodes?
> Use patch 2/2 of this series to make them additional pm-busses or move the
> ls-ext-irq nodes outside of it?

To move the ls-extirq nodes outside of syscon means that we break
compatibility with the old device trees which I don't like.

I would much more prefer to use the approach in patch 2/2 of making the
scfg/isc nodes pm-busses.

Ioana

Re: [PATCH v2 1/2] irqchip/ls-extirq: convert to a platform driver

[Alexander Stein]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

Hi,

Am Freitag, 12. Dezember 2025, 15:17:05 CET schrieb Ioana Ciornei:
> On Fri, Dec 12, 2025 at 10:51:12AM +0100, Alexander Stein wrote:
> > Hi,
> > 
> > thanks for bringing this to me.
> > 
> > Am Freitag, 12. Dezember 2025, 02:24:19 CET schrieb Thomas Gleixner:
> > > On Fri, Dec 05 2025 at 17:57, Ioana Ciornei wrote:
> > > > Since there is no need for ls-extirq to be initialized early, convert it
> > > > to a proper platform driver. Instead of using IRQCHIP_DECLARE, add an
> > > > of_device_id array with the same compatible strings as before. Also
> > > > change the prototype and name of the probe function and adjust it to a
> > > > platform_device structure.
> > > >
> > > > With this change we also have the added advantage of avoiding the
> > > > irqchip_init() -> of_irq_init() code path which imposes dt checks that
> > > > the ls-extirq does not comply with because of its improper use of the
> > > > interrupt-map property.
> > > >
> > > > Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")
> > > 
> > > I'm not seeing how that Fixes tag is related. Your changelog clearly
> > > lacks a proper explanation.
> > > 
> > > Aside of that there is this series:
> > > 
> > >       https://lore.kernel.org/20251201105144.539450-1-alexander.stein@ew.tq-group.com
> > > 
> > > which is way more complete and cleans up the thing nicely instead of
> > > just converting it to a platform driver with minimal effort.
> > 
> > There is still one open question: How to deal with the scfg/isc nodes?
> > Use patch 2/2 of this series to make them additional pm-busses or move the
> > ls-ext-irq nodes outside of it?
> 
> To move the ls-extirq nodes outside of syscon means that we break
> compatibility with the old device trees which I don't like.

Yep, me too.

> I would much more prefer to use the approach in patch 2/2 of making the
> scfg/isc nodes pm-busses.

To be honest I'm not fond of it, but if this is the way to keep
compatiblity, why not?
Let's see what maintainers comment on that.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/2] irqchip/ls-extirq: convert to a platform driver

[Ioana Ciornei]

On Fri, Dec 12, 2025 at 10:24:19AM +0900, Thomas Gleixner wrote:
> On Fri, Dec 05 2025 at 17:57, Ioana Ciornei wrote:
> > Since there is no need for ls-extirq to be initialized early, convert it
> > to a proper platform driver. Instead of using IRQCHIP_DECLARE, add an
> > of_device_id array with the same compatible strings as before. Also
> > change the prototype and name of the probe function and adjust it to a
> > platform_device structure.
> >
> > With this change we also have the added advantage of avoiding the
> > irqchip_init() -> of_irq_init() code path which imposes dt checks that
> > the ls-extirq does not comply with because of its improper use of the
> > interrupt-map property.
> >
> > Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")
> 
> I'm not seeing how that Fixes tag is related. Your changelog clearly
> lacks a proper explanation.
> 

The referenced commit added a check against the presence of the
'interrupts' property for an interrupt controller and only if it exist
it will then call of_irq_find_parent() to gets it IRQ parent.
This change basically broke the ls-extirq.

Converting ls-extirq to a platform driver we are basically avoiding the
irqchip_init() -> of_irq_init() path.

> Aside of that there is this series:
>
>       https://lore.kernel.org/20251201105144.539450-1-alexander.stein@ew.tq-group.com
>
> which is way more complete and cleans up the thing nicely instead of
> just converting it to a platform driver with minimal effort.
>

Thanks. I wasn't aware of this series. I will have a look.

Ioana

[PATCH v2 2/2] bus: simple-pm-bus: probe the Layerscape SCFG node

[Ioana Ciornei]

Make the simple-pm-bus driver probe the Layerscape SCFG dt nodes and
populate platform_device from its child dt nodes.

This is now needed because its child interrupt-controller - ls-extirq -
is being handled as a platform_device instead of being initialized
through the IRQCHIP_DECLARE infrastructure.

Fixes: 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes without interrupts")
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in v2:
- none
 drivers/bus/simple-pm-bus.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
index d8e029e7e53f..3f00d953fb9a 100644
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -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 },
 	{ .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);
-- 
2.25.1

Re: [PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[Vladimir Oltean]

Hello,

On Fri, 5 Dec 2025 at 17:58, Ioana Ciornei <ioana.ciornei@nxp.com> wrote:
>
> Starting with commit 1b1f04d8271e ("of/irq: Ignore interrupt parent for
> nodes without interrupts"), the ls-extirq stopped working. This is
> because ls-extirq, being one of the interrupt-map property abusers,
> does not pass the dt checks added by the referenced commit, making it
> unable to determine its interrupt parent.
>
> Instead of reverting the referenced commit, convert the ls-extirq to a
> platform driver so that we avoid completely the irqchip_init() ->
> of_irq_init() code path. This is what patch 1/2 does.
>
> Patch 2/2 makes the parent dt nodes of ls-extirq to get probed by the
> simple-pm-bus driver, for the single goal of it running
> of_platform_populate(). Without this patch, the simple-pm-bus will not
> get to probe on the ls-extirq nodes.
>
> Alternative fixup routes were discussed in the following thread.
> https://lore.kernel.org/all/CAL_JsqJ4q2=UJbuhfbvsbr2T+SRGXsPSXCLk6iXZid_qwYrN4g@mail.gmail.com/
>
> Changes in v2:
> - Use builtin_platform_driver since the driver cannot be built as a
>   module
>
> Ioana Ciornei (2):
>   irqchip/ls-extirq: convert to a platform driver
>   bus: simple-pm-bus: probe the Layerscape SCFG node
>
>  drivers/bus/simple-pm-bus.c     |  6 ++++++
>  drivers/irqchip/irq-ls-extirq.c | 32 +++++++++++++++++++++++++++-----
>  2 files changed, 33 insertions(+), 5 deletions(-)
>
> --
> 2.25.1

Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>

These patches are needed on the LX2160A-RDB, where they fix the following issue:

[    0.000000] irq-ls-extirq: Cannot find parent domain
[    0.000000] OF: of_irq_init: Failed to init
/soc/syscon@1f70000/interrupt-controller@14 ((____ptrval____)), parent
0000000000000000
(...)
[   16.372899] mdio_bus 0x0000000008b96000:01: deferred probe timeout,
ignoring dependency
[   16.386223] mdio_bus 0x0000000008b96000:02: deferred probe timeout,
ignoring dependency
[   16.477556] mdio_bus 0x0000000008b96000:00: deferred probe timeout,
ignoring dependency
[   16.567641] mdio_bus 0x0000000008b96000:08: deferred probe timeout,
ignoring dependency
[   16.569071] mdio_bus 0x0000000008b96000:01: deferred probe pending:
mdio_bus: wait for supplier
/soc/syscon@1f70000/interrupt-controller@14
[   16.569080] mdio_bus 0x0000000008b96000:02: deferred probe pending:
mdio_bus: wait for supplier
/soc/syscon@1f70000/interrupt-controller@14
[   16.569085] mdio_bus 0x0000000008b96000:00: deferred probe pending:
mdio_bus: wait for supplier
/soc/syscon@1f70000/interrupt-controller@14
[   16.569090] mdio_bus 0x0000000008b96000:08: deferred probe pending:
mdio_bus: wait for supplier
/soc/syscon@1f70000/interrupt-controller@14

I agree with Thomas' comments on patch 1 that the commit message is telling us
the conclusion without telling us what the problem is.

However, between this solution and Alexander's, this is clearly preferable,
because it does not break device trees.

I think this patch set has stalled possibly due to the holiday season, but my
understanding that a v2 is due with an updated commit message and nothing else,
correct?

Thanks,
Vladimir

Re: [PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[Thomas Gleixner]

On Tue, Jan 13 2026 at 17:33, Vladimir Oltean wrote:
> On Fri, 5 Dec 2025 at 17:58, Ioana Ciornei <ioana.ciornei@nxp.com> wrote:
>
> I agree with Thomas' comments on patch 1 that the commit message is telling us
> the conclusion without telling us what the problem is.
>
> However, between this solution and Alexander's, this is clearly preferable,
> because it does not break device trees.

I'm fine with that, though the extra cleanups Alexander did are nice...

> I think this patch set has stalled possibly due to the holiday season, but my
> understanding that a v2 is due with an updated commit message and nothing else,
> correct?

Yes. I've marked it "wait for update" and that's the state since
Dec. 5th.

Thanks,

        tglx

Re: [PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[Vladimir Oltean]

Hi Thomas,

On Tue, Jan 13, 2026 at 07:36:48PM +0100, Thomas Gleixner wrote:
> On Tue, Jan 13 2026 at 17:33, Vladimir Oltean wrote:
> > On Fri, 5 Dec 2025 at 17:58, Ioana Ciornei <ioana.ciornei@nxp.com> wrote:
> >
> > I agree with Thomas' comments on patch 1 that the commit message is telling us
> > the conclusion without telling us what the problem is.
> >
> > However, between this solution and Alexander's, this is clearly preferable,
> > because it does not break device trees.
> 
> I'm fine with that, though the extra cleanups Alexander did are nice...
> 
> > I think this patch set has stalled possibly due to the holiday season, but my
> > understanding that a v2 is due with an updated commit message and nothing else,
> > correct?
> 
> Yes. I've marked it "wait for update" and that's the state since
> Dec. 5th.
> 
> Thanks,
> 
>         tglx

Thanks for the response. I've since looked at the code, and Alexander's
cleanups are more than "nice", they are required, because when you
convert a driver from IRQCHIP_DECLARE() to platform_driver, you
introduce the possibility for it to be unbound from the device, and when
you do that, the memory that ls_extirq_probe() has allocated needs to be
freed.

Ioana's patch doesn't do that; Alexander's does (although possibly
unintended). I suspect the best parts of their approaches needs to be
squashed into a single change and both authors credited (separate
changes would mean introducing the memory leak just to fix it in the
next patch).

Ioana, Alexander, could you please start a discussion to see who can
submit the follow up to this thread?

Thanks!
Vladimir

Re: [PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[Thomas Gleixner]

On Tue, Jan 13 2026 at 20:43, Vladimir Oltean wrote:
> On Tue, Jan 13, 2026 at 07:36:48PM +0100, Thomas Gleixner wrote:
>> Yes. I've marked it "wait for update" and that's the state since
>> Dec. 5th.
>
> Thanks for the response. I've since looked at the code, and Alexander's
> cleanups are more than "nice", they are required, because when you
> convert a driver from IRQCHIP_DECLARE() to platform_driver, you
> introduce the possibility for it to be unbound from the device, and when
> you do that, the memory that ls_extirq_probe() has allocated needs to be
> freed.

Oh, didn't look in that detail. Thanks for catching it!

> Ioana, Alexander, could you please start a discussion to see who can
> submit the follow up to this thread?

Yes please.

Re: [PATCH v2 0/2] irqchip: convert ls-extirq to a platform driver

[Ioana Ciornei]

On Tue, Jan 13, 2026 at 09:20:02PM +0100, Thomas Gleixner wrote:
> On Tue, Jan 13 2026 at 20:43, Vladimir Oltean wrote:
> > On Tue, Jan 13, 2026 at 07:36:48PM +0100, Thomas Gleixner wrote:
> >> Yes. I've marked it "wait for update" and that's the state since
> >> Dec. 5th.
> >
> > Thanks for the response. I've since looked at the code, and Alexander's
> > cleanups are more than "nice", they are required, because when you
> > convert a driver from IRQCHIP_DECLARE() to platform_driver, you
> > introduce the possibility for it to be unbound from the device, and when
> > you do that, the memory that ls_extirq_probe() has allocated needs to be
> > freed.
> 
> Oh, didn't look in that detail. Thanks for catching it!
> 
> > Ioana, Alexander, could you please start a discussion to see who can
> > submit the follow up to this thread?
> 
> Yes please.

What I propose is for me to submit a v3 which squashes Alexander's 3/3
patch (the managed resource changes) into this 2/2 patch.

The alternative would be to extend this 2/2 patch by adding a .remove()
callback only for it to be removed in the next patch which does the
conversion to devres. I don't think that is necessary or even desired.

Alexander, please let me know if you have any objections to this
approach.

Ioana