On Sat, Aug 9, 2014 at 1:48 AM, Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx> wrote: > From: Tomasz Figa <t.figa@xxxxxxxxxxx> > > Currently after configuring a GPIO pin as an interrupt related pinmux > registers are changed, but there is no protection from calling > gpio_direction_*() in a badly written driver, which would cause the same > pinmux register to be reconfigured for regular input/output and this > disabling interrupt capability of the pin. > > This patch addresses this issue by moving pinmux reconfiguration to > .irq_{request,release}_resources() callback of irq_chip and calling > gpio_lock_as_irq() helper to prevent reconfiguration of pin direction. > > Setting up a GPIO interrupt on Samsung SoCs is a two-step operation - > in addition to trigger configuration in a dedicated register, the pinmux > must be also reconfigured to GPIO interrupt, which is a different function > than normal GPIO input, although I/O-wise they both behave in the same way > and gpio_get_value() can be used on a pin configured as IRQ as well. > > Such design implies subtleties such as gpio_direction_input() not having > to fail if a pin is already configured as an interrupt nor change the > configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by > gpio_lock_as_irq() is only used to check that gpio_direction_output() is > not called, it's not used to prevent gpio_direction_input() to be called. > So this is not a complete solution for Samsung SoCs but it's definitely a > move in the right direction. > > Signed-off-by: Tomasz Figa <t.figa@xxxxxxxxxxx> > [javier: use request resources instead of startup and expand commit message] > Signed-off-by: Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx> > --- > > This patch solves the issue explained in https://lkml.org/lkml/2014/8/8/461 Hm, this looks much better atleast, it is not possible to use the irqchip helpers from gpiolib then, because that grabs the request/release resource callbacks. If I get some ACKs on this we can go for this solution. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html