On Fri, Aug 30, 2013 at 10:08 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 08/29/2013 01:00 PM, Linus Walleij wrote: >> No but I think there should be one ... maybe I'm an oddball >> but it seems natural to request a GPIO before tying >> IRQs to fire off it. > > What if there is no GPIO? > > There are plenty of chips with dedicated IRQ input pins that can't be > read as GPIOs, or treated as GPIOs in any way. I'm not following this. In that case it is not tagged as gpio-controller right? The patch is to gpiolib.c. Do you mean chips where some part of it is GPIO and another part is IRQ-only? Should we not in that case create an MFD device that spawns one GPIO device and then another irqchip device, or possibly have the IRQ handling directly in the MFD device, as ab8500-core.c does? > If a driver only needs IRQ input functionality, it should just request > an IRQ and be done with it. There should be no need at all for the > driver to know that the IRQ might be routed into a GPIO controller, and > hence that the driver may (or may not) need to additionally request the > GPIO before requesting the IRQ. This is what the patch is trying to achieve, for the DT use case. > In other words, request_irq() must do everything necessary for the input > signal to operate as an IRQ input, irrespective of whether it might be > possible to use that input signal as a GPIO. That is not the case for a bunch of OMAP drivers today, and their attempt to fix that inside the irqchip callback backfired since it was mutually exclusive with requesting the gpio first. We have to encode some semantic into this, it's just a matter of which one shall win, the APIs as they stand are ambiguous wrt call sequence. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
