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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
