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

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

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

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/

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

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/