Re: [PATCH 02/16] drivers/gpio: gpio-nomadik: Add support for irqdomains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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]

Add to Google Follow linuxarm on Twitter