On 04/10/2013 03:28 PM, Linus Walleij wrote: > On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >> On 04/10/2013 12:12 PM, Linus Walleij wrote: > >>> If the information is there, whether to convert from IRQ to GPIO >>> or from GPIO to IRQ is a technicality and any order should be >>> feasible in some way? >> >> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put >> another way, a single GPIO would likely only ever trigger a single IRQ, >> but a single IRQ might easily be triggered by any number of GPIOs. This >> is exactly why the function irq_to_gpio() isn't something one should use >> any more. I think there was an effort to outright remove the API, >> although it doesn't look like that's entirely complete yet. I guess you >> know this given your mentions of problem with gpio_to_irq() later on, so >> I'm not quite sure what your paragraph above was supposed to mean. > > So the only reason I'm rambing on about this is that it breaks the I'm not sure I understand this paragraph; what is "it" in the line above. If "it" is this patch, then should "breaks" be re-establishes? > connection between GPIOs and their IRQs and at one point > I percieved it as there was going to be some IRQ -> GPIO lookup, > and it would sneak back in. But now I realize that may have been > supposed to be something local to the driver, in it's irqchip portions > and then it's actually no problem for the kernel at large. Yes, I believe the intention was for their to be a correlation between GPIOs and IRQs only with the individual gpio_chip/irq_chip drivers for those GPIOs/IRQs, and not exposed anywhere outside it. > Let's restate: I'm also after something fragile here. I assume you mean the opposite of that? > IIUC, it will be possible for a GPIO to be set up as input and used > as an IRQ without the GPIO subsystem knowing it. And it will be > possible for the GPIO subsystem to go in and request the same pin > and set it as output and e.g. bit-bang it. I wonder what happens then. Yes, I think that's possible now. If I recall the patch I'm replying to correctly, the idea was to add an "IRQ request" operation that would (internally to the GPIO/IRQ driver itself) map IRQ->GPIO, and call gpio_request(). That would then prevent exactly the situation you mention above. -- 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
