On Thu, May 29, 2014 at 05:22:05PM +0200, Linus Walleij wrote: > On Thu, May 29, 2014 at 6:03 PM, Grygorii Strashko > <grygorii.stras...@ti.com> wrote: > > > Also, I'd like to note that GPIO IRQs can be accessible not only > > when GPIO chips is added, but also when IRQ domain is registered > > (at least it's valid for DT cases). In these cases gpiod_to_irq() > > might be not used at all. > > Yes. We concluded some time back that gpio_chip:s and > irq_chip:s are orthogonal abstractions: you should be able > to use one of them without paying any respect to the other. > > We only added the ability to flag GPIO lines as used for > IRQs so they would not be set to output by mistake... > (Straightening up the semantics.) > > The only real semantic dependence that really makes sense > is .to_irq() which leads to this semantic registration ordering.
acpi_gpiochip_request_interrupts() depends on ->to_irq() to be set before acpi_gpiochip_add() is called. Since the ordering changes this won't work anymore. I'm thinking that could we solve this so that we call acpi_gpiochip_request_interrupts() at the end of gpiochip_irqchip_add() and convert both pinctrl-baytrail and gpio-lynxpoint to use gpiochip_irqchip_add()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
