Am Freitag, 30. August 2013, 13:55:26 schrieb Stephen Warren: > On 08/29/2013 06:24 PM, Javier Martinez Canillas wrote: > ... > > > We have been trying to solve this issue for a few months by now and Linus' > > approach seems to be the most sensible solution to me. > > > > Drivers that request an IRQ and assume that platform code will request and > > setup the GPIO have been broken since the boards using these drivers were > > migrated to DT (e.g: smsc911x on OMAP2+ boards). > > That's only true if the driver for the GPIO controller is buggy. > Whatever request_irq() maps down to in the GPIO/IRQ controller driver > simply needs to set up the pin as an interrupt input, then it doesn't > matter which order the driver does things. Is it really that easy? request_irq() should request the gpio and set it to input that it needs to fulfill the irq request. That would then be the way to go for new drivers and in the DT case. Some leagcy drivers currently do this: request_gpio(gpio); gpio_direction_input(gpio); request_irq(gpio_to_irq(gpio)); In that case request_irq should not fail because the driver is already the correct owner of this gpio. But if some other entity owns this gpio it should fail. Also if I understand you correct the other way round should also possible: request_irq(gpio_to_irq(gpio)); request_gpio(gpio); gpio_direction_input(gpio); request_irq() also requests the gpio then but the following request_gpio() should also not fail. To have it work that way we have to track the owners of all requested gpios somewhere. Or am I wrong here? Where and how to record these owners? Can gpio system achieve this? gpios are requested without an owning device. -- 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
