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

[Barry Song]

2014-01-16 Barry Song <21cnbao@xxxxxxxxx>:
>
>> From: Linus Walleij [linus.walleij@xxxxxxxxxx]
>> Sent: Wednesday, January 15, 2014 17:10
>> To: linux-kernel@xxxxxxxxxxxxxxx; Barry Song
>> Cc: linux-gpio@xxxxxxxxxxxxxxx; Linus Walleij
>> Subject: [PATCH] pinctrl: sirf: lock IRQs when starting them
>>
>> This uses the new API for tagging GPIO lines as in use by
>> IRQs. This enforces a few semantic checks on how the underlying
>> GPIO line is used.
>>
>> Also assign the gpio_chip.dev pointer to be used for error
>> messages.
>>
>> Cc: Barry Song <Baohua.Song@xxxxxxx>
>> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>

Hi Linus,
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.
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, who will fix the availability of this pin if it is
muxed with other functionality except gpio?

for example, in case pin0 can be gpio0 and spi0, if we
request_irq(gpio0) without calling gpio_request(gpio0), and the other
people can still request the pin0 for spi0 since we didn't mark the
pin was used by irq or gpio yet.

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? but this might be buggy again since people might call
gpio_request() before calling request_irq().

>
>> ---
>>  drivers/pinctrl/sirf/pinctrl-sirf.c | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>

-barry
--
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/