* Grant Likely <[email protected]> [140424 09:11]: > On Wed, 23 Apr 2014 16:42:13 -0700, Tony Lindgren <[email protected]> wrote: > > * Rob Herring <[email protected]> [140423 15:58]: > > > From: Rob Herring <[email protected]> > > > > > > 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 <[email protected]> > > > Signed-off-by: Rob Herring <[email protected]> > > > Signed-off-by: Tony Lindgren <[email protected]> > > > > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
