On Friday 23 August 2013 at 21:52:20, Stephen Warren wrote: > On 08/23/2013 12:45 PM, Linus Walleij wrote: > > 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)); > > But I'm not aware that there's a rule saying it's illegal to: > > request_irq(gpio_to_irq(gpio)); > request_gpio(gpio); > gpio_direction_input(gpio); But I'd consider this as a bug. What if the scheduler interrupts you right after you requested (and got assigned) the interrupt and another entity requests your gpio? Then you'd have a resource conflict, because you are not the owner of the gpio you requested an interrupt for. -- 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
