On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote: > On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter <jon-hunter@xxxxxx> wrote: >> >> On 02/26/2013 06:13 PM, Stephen Warren wrote: >>> On 02/26/2013 04:45 PM, Jon Hunter wrote: ... >>>> One issue I see is that by not calling gpio_request, then potentially >>>> you could have someone request a gpio via gpio_request() and someone >>>> trying to use it as an interrupt source via request_irq(). Now obviously >>>> that represents a bug because there is only one physical gpio, but I >>>> gather it is something we need to protect against. >>> >>> I'm not sure it's really that much of an issue, but presumably the >>> solution is for a combined GPIO+IRQ driver to simply call gpio_request >>> internally from within some irq_chip function. It looks like struct >>> irq_chip doesn't have a request/free, but perhaps they could be added to >>> solve this? >> >> Yes I was wondering if we could do something like that. That would work, >> may be that's what we should propose. > > Something like that would definitely solve the GPIO request issue but > we still have the issue that the current OMAP GPIO controller binding > does not support #interrupt-cells = <2>. The binding documentation in Documentation/devicetree/bindings/gpio/gpio-omap.txt indicates that it does. If this doesn't work in practice, it's a driver bug that can presumably be easily fixed. And no need to change any ABI definitions:-) BTW, I notice in that binding document that the description of the two cells for #interrupt-cells is actually part of the description of the "interrupt-controller" property; it should be moved up one line really. -- 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
