Re: [PATCH 2/2] of/irq: do irq resolution in platform_get_irq

From: Tony Lindgren
Date: Thu Apr 24 2014 - 13:19:36 EST


* Grant Likely <grant.likely@xxxxxxxxxx> [140424 09:11]:
> On Wed, 23 Apr 2014 16:42:13 -0700, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > * Rob Herring <robherring2@xxxxxxxxx> [140423 15:58]:
> > > From: Rob Herring <robh@xxxxxxxxxx>
> > >
> > > Currently we get the following kind of errors if we try to use interrupt
> > > phandles to irqchips that have not yet initialized:
> > >
> > > irq: no irq domain found for /ocp/pinmux@48002030 !
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
> > > (show_stack+0x14/0x1c)
> > > (dump_stack+0x6c/0xa0)
> > > (warn_slowpath_common+0x64/0x84)
> > > (warn_slowpath_null+0x1c/0x24)
> > > (of_device_alloc+0x144/0x184)
> > > (of_platform_device_create_pdata+0x44/0x9c)
> > > (of_platform_bus_create+0xd0/0x170)
> > > (of_platform_bus_create+0x12c/0x170)
> > > (of_platform_populate+0x60/0x98)
> > >
> > > This is because we're wrongly trying to populate resources that are not
> > > yet available. It's perfectly valid to create irqchips dynamically, so
> > > let's fix up the issue by resolving the interrupt resources when
> > > platform_get_irq is called.
> > >
> > > And then we also need to accept the fact that some irqdomains do not
> > > exist that early on, and only get initialized later on. So we can
> > > make the current WARN_ON into just into a pr_debug().
> > >
> > > We still attempt to populate irq resources when we create the devices.
> > > This allows current drivers which don't use platform_get_irq to continue
> > > to function. Once all drivers are fixed, this code can be removed.
> > >
> > > Suggested-by: Russell King <linux@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
> > > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> >
> > Great, works for me. Hopefully this patch is non-intrusive enough for
> > people for the -rc cycle too?
>
> Both patches look good. I've put them in my tree and will push it out
> shortly. I want to make sure there are no regressions on PowerPC, so
> I'll give it a few days in linux-next before asking Linus to pull.

Great, sounds good to me.

> Tony, how far back does this need to be backported?

The issue seems to have been around ever since the start of DT with
platform_bus, and people have been probably working around it with
the initcall levels and using irq_of_parse_and_map instead of
platform_get_irq.

I noticed the issue last year around the time interrupts-extended
binding patches were posted and I was adding the irqdomain support
to pinctrl-single.c for wake-up interrupts.

So the fix should probably go back to at least v3.12 or v3.10 as
those are recent longterm kernels. The patch seems to apply to both
of them with fuzz except for include/linux/of_irq.h.

Sligthly related to this patch, also 4a43d686fe33 (of/irq: Pass
trigger type in IRQ resource flags) should also get tagged stable
too if not done already as that keeps some legacy drivers working.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/