|
|
Re: [PATCH 02/16] drivers/gpio: gpio-nomadik: Add support for irqdomains |
On Thu, 19 Apr 2012 22:01:47 -0500, Rob Herring <robherring2@xxxxxxxxx> wrote: > On 04/19/2012 11:23 AM, Arnd Bergmann wrote: > > On Wednesday 18 April 2012, Linus Walleij wrote: > >> > >> On Wed, Apr 18, 2012 at 6:22 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > >>> The problem is that we cannot put the interrupt resources into the platform > >>> device until the irq domain has been added. Right now, we set the gic > >>> interrupt domain from init_IRQ(), then add the load the gpio > >>> driver from core_initcall(nmk_gpio_init) and add the platform devices > >>> from arch_initcall(customize_machine). > >>> > >>> This feels fragile because it depends on the gpio device getting probed > >>> before any device using the gpio interrupts. It does seem to work fine > >>> right now, but I'm not convinced that this is just coincidence. > >> > >> Aha OK. Why not put in that big comment then, thus nobody will > >> ever miss the point like I did :-) > >> > > > > I think I've just come up with a solution to this problem and would > > like to hear what Rob and Grant think about this: > > > > If we move the code that adds the resources to a platform_device > > from of_device_alloc() to platform_drv_probe(), we can defer > > looking up the interrupt number until the driver actually gets > > probed and bail out early with -EPROBE_DEFER if the irq domain > > is not available yet. That will even work when we have a builtin > > driver for a device that uses a GPIO interrupt and the gpio controller > > driver is a loadable module. > > > > That certainly seems like a plausible solution and I don't have any > thing better to suggest. Does that affect non-DT platform devices in a > negative way? I've been thinking about doing something like this for a while. If drivers are encouraged to use something like platform_get_irq(), or maybe a more generic interface for more than just platform devices, then there can be hooks in there to resolve irqs at probe time instead of device creation time. So I certainly support that approach. g. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[Linux ARM (vger)] [Linux ARM MSM] [Linux Omap] [Linux Arm] [Linux Tegra] [Fedora ARM] [eCos] [Linux Fastboot] [Gcc Help] [Git] [DCCP] [IETF Announce] [Security] [PDAs] [Linux] [Linux MIPS] [Yosemite Campsites] [Photos]
![]() |
![]() |