On Fri, Aug 23, 2013 at 9:52 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 08/23/2013 12:45 PM, Linus Walleij wrote: >> 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); No but I think there should be one ... maybe I'm an oddball but it seems natural to request a GPIO before tying IRQs to fire off it. Besides, the bug that this is trying to solve is due to the fact that the OMAP driver require exactly the former order for the IRQs to work. I think if the sequence matters it is likely to be the first form, but it's a rough guess. >> Pass only the GPIO in the device tree and this works just fine. > > And I wouldn't be surprised if there were DTs that had separate GPIO and > interrupt entries for the same pin. That is the situation we want to catch. Don't you agree that it has some bit of ambiguity around it, like the tree makes an assumtion that whether you ask for the GPIO line or IRQ first does not matter, and leave it up to the driver to "do something" if the order suddenly turns out the other way around, but is important to the hardware? I think we can't get away from the ambition to define this semantic for all DT systems. > In fact, it's arguably technically > more correct to do that than just list the GPIO, and then hope the OS > will be able to convert it to the correct IRQ. Then, drivers wouldn't > have any reason to believe they needed a specific IRQ-vs-GPIO request > ordering. If that is more technically correct (hm I wonder what measure is used for "correctness" here) I think we are back at the GPIO input hogs to achive what OMAP needs. Using such hogs they can let the gpiochip node hog a few pins and set them as input rather than each and every driver having to do so. 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
