2014-01-16 Barry Song <21cn...@gmail.com>: > >> From: Linus Walleij [linus.wall...@linaro.org] >> Sent: Wednesday, January 15, 2014 17:10 >> To: linux-kernel@vger.kernel.org; Barry Song >> Cc: linux-g...@vger.kernel.org; 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.s...@csr.com> >> Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
