On Mon, Apr 15, 2013 at 11:40 PM, Jon Hunter <jon-hunter@xxxxxx> wrote: > I am still concerned about the case where a driver may have already > called gpio_request() and then calls request_irq(). I think that the > solution needs to handle cases where the driver may or may not call > gpio_request() to allocate the gpio. So take a step back and you see that this is my actual fear and why I'm so hesitant about this patch to begin with. I wanted drivers to follow the sequence: gpio_request(), gpio_to_irq(), request_irq() Now if request_irq() can implicitly perform gpio_request(), we end up with a semantic confusing mess like this where we are uncertain as to whether we should use the irq we obtain elsewhere (like from a resource on the platform device)) or maybe use gpio_to_irq() to convert it into an IRQ or not or ... It is certainly true that for some devices we don't want to know if the IRQ comes from a hard-wired IRQ line or from a GPIO line playing the rôle of IRQ controller, so we need to handle that. But then the drivers need to be consistent, and relying solely on code review to stop people from doing mixtures like the described is not working, the subsystem must enforce a proper policy. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
