On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > 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. Yes? Are we talking past each other here? This is a perfectly OK thing to do as long as it is done like this: request_gpio(gpio); gpio_direction_input(gpio); request_irq(gpio_to_irq(gpio)); Pass only the GPIO in the device tree and this works just fine. The use case after that we do not interfer with. Yours, Linus Walleij -- 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
