[PATCH 3/5] gpio/omap: Add DT support to GPIO driver

[Javier Martinez Canillas]

On Wed, Feb 27, 2013 at 6:50 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote:
>> On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter <jon-hunter at ti.com> 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:-)
>

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