Re: [PATCH] pinctrl: sirf: lock IRQs when starting them

[Linus Walleij]

On Mon, Jan 27, 2014 at 8:01 AM, Barry Song <21cnbao@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/