Thread (32 messages) 32 messages, 6 authors, 2013-09-03

Re: [PATCH v2] gpio: interrupt consistency check for OF GPIO IRQs

From: Lars Poeschel <hidden>
Date: 2013-09-02 09:47:36
Also in: linux-gpio, lkml

Am Freitag, 30. August 2013, 14:08:41 schrieb Stephen Warren:
On 08/29/2013 01:00 PM, Linus Walleij wrote:
quoted
On Fri, Aug 23, 2013 at 9:52 PM, Stephen Warren [off-list ref] 
wrote:
quoted
quoted
On 08/23/2013 12:45 PM, Linus Walleij wrote:
quoted
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.
What if there is no GPIO?
If there is no GPIO there is no gpio-controller and there is no problem.
There are plenty of chips with dedicated IRQ input pins that can't be
read as GPIOs, or treated as GPIOs in any way.

If a driver only needs IRQ input functionality, it should just request
an IRQ and be done with it. There should be no need at all for the
driver to know that the IRQ might be routed into a GPIO controller, and
hence that the driver may (or may not) need to additionally request the
GPIO before requesting the IRQ.
Yes, you're right, but reality is different. Legacy drivers / board-files do:

request_gpio(gpio);
gpio_direction_input(gpio);
request_irq(gpio_to_irq(gpio));
 
In other words, request_irq() must do everything necessary for the input
signal to operate as an IRQ input, irrespective of whether it might be
possible to use that input signal as a GPIO.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help