On Wed, Feb 27, 2013 at 6:50 PM, Stephen Warren [off-list ref] wrote:

On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote:

quoted

On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter [off-list ref] wrote:

quoted

On 02/26/2013 06:13 PM, Stephen Warren wrote:

quoted

On 02/26/2013 04:45 PM, Jon Hunter wrote:

...

quoted

quoted

quoted

quoted

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:-)

indeed :-)

In fact I think that some documentation bits were borrowed from the
NVIDIA Tegra GPIO controller bindings but it was never implemented in
the OMAP GPIO driver to parse the second interrupt-cell which should
specify the flags.

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.

Right, will submit a patch to fix this.

Best regards,
Javier