Messages in this thread | | | Date | Mon, 27 Jan 2014 11:02:15 +0100 | Subject | Re: [PATCH] pinctrl: sirf: lock IRQs when starting them | From | Linus Walleij <> |
| |
On Mon, Jan 27, 2014 at 8:01 AM, Barry Song <21cnbao@gmail.com> wrote:
> i read the patch "gpio: add API to be strict about GPIO IRQ usage" > again, it seems by checking if (test_bit(FLAG_USED_AS_IRQ, > &desc->flags)), we do be able to stop users setting irqline to output.
Yes that is the specific use of that flag right now.
> but my concern is actually that: when users use request_irq to get the > irq line from gpio, in that case, gpio_request() probably will not be > called at all,
This question has come up a lot recently as we recently established that irqchip and gpiolib APIs are orthogonal, just like you say.
> who will fix the availability of this pin if it is > muxed with other functionality except gpio?
So the problem is with the established semantic that irqchips and gpiochips are orthogonal, not with this particular patch, right?
Muxing is the responsibility of the pin control pin mux subsystem and not GPIO.
If you require pinctrl_request_gpio() to be called from the gpiolib driver for the pin to be muxed in, then this function must be called from the irqchip side as well, e.g. from .irq_startup().
> but if gpio_request() is called, in it, pinctrl_request_gpio() is > called as well, which will mark the pin as not-free. so do you think > we need to call pinctrl_request_gpio() in startup() of irqline as > well?
I think so.
> but this might be buggy again since people might call > gpio_request() before calling request_irq().
Hm, you should study this problem and suggest the best solution. In general I do not think it hurts to call pinctrl_request_gpio() multiple times, and if it does maybe that is something we want to fix?
Yours, Linus Walleij
| |