Re: [PATCH v2] gpio: interrupt consistency check for OF GPIO IRQs

[Stephen Warren]

On 08/21/2013 05:36 PM, Linus Walleij wrote:
> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> [Me]
>>>> check if these in turn reference the interrupt-controller, and
>>>> if they do, loop over the interrupts used by that child and
>>>> perform gpio_request() and gpio_direction_input() on these,
>>>> making them unreachable from the GPIO side.
>>
>> What about bindings that require a GPIO to be specified, yet don't allow
>> an IRQ to be specified, and the driver internally does perform
>> gpio_to_irq() on it? I don't think one can detect that case.
> 
> This is still allowed. Consumers that prefer to have a GPIO
> passed and convert it to IRQ by that call can still do so,
> they will know what they're doing and will not cause the
> double-command situation that we're trying to solve.

Why not? There are certainly drivers in the kernel which request a GPIO
as both a GPIO and as an (dual-edge) interrupt, so that they can read
the GPIO input whenever the IRQ goes off, in order to determine the pin
state. This is safer against high-latency or lost interrupts.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/