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

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

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

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

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.

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