Messages in this thread | | | Date | Fri, 30 May 2014 11:25:03 +0300 | From | Mika Westerberg <> | Subject | Re: [PATCH v4] gpio: Add support for Intel SoC PMIC (Crystal Cove) |
| |
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.strashko@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()?
| |