On 08/23/2013 01:55 PM, Tomasz Figa wrote: > On Friday 23 of August 2013 13: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); > > Well, at least on Samsung platforms it is illegal to do so, because > gpio_direction_input() would override the interrupt+input function set by > setup done in request_irq() with normal input function, thus breaking the > interrupt. Assuming that Linux has no general rule that requires a specific order, isn't that simply a bug in the Samsung platforms? After all, a completely generic cross-platform driver, which could touch both GPIO and IRQ, would be written to any Linux-imposed rules, not any Samsung-platform-imposed rules. > We are still to implement some sanity check to disallow (or ignore) this > if the pin is already configured as an interrupt. OK good, so it sounds like this is a temporary issue. -- 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
