There are cases when the bootloader configures a pin to work as a function rather than GPIO, and other cases when the pin is configured as a function at POR. This commit makes sure the pin is configured as a GPIO the moment we need it to work as an interrupt. Signed-off-by: Fabrizio Castro <fabrizio.castro@xxxxxxxxxxxxxx> --- Dear All, we have got some issues while trying to bring up the interrupt line of the HDMI transmitter on the iwg23s, as GP2_29 is configured as a function when the kernel starts, and therefore setting up the interrupt from the driver won't have the desired effect. This patch makes sure the pinctrl driver sets GP2[29] to GP-2-29 before enabling the interrupt, but it doesn't addresses the "direction problem", as in the pin will be a GPIO after calling gc->request, but the direction would be whatever was previously configured. There could be the option of moving the additional code added by this patch to the bottom of function gpio_rcar_irq_set_type, but is that going to behave properly on every SoC this driver is supporting? Is configuring every gpio with direction input while probing something that should be looked into to reduce concerns over switching from function to GPIO? Comments very welcome! Thanks, Fab drivers/gpio/gpio-rcar.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c index 3c82bb3..8c69431 100644 --- a/drivers/gpio/gpio-rcar.c +++ b/drivers/gpio/gpio-rcar.c @@ -147,6 +147,14 @@ static int gpio_rcar_irq_set_type(struct irq_data *d, unsigned int type) struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct gpio_rcar_priv *p = gpiochip_get_data(gc); unsigned int hwirq = irqd_to_hwirq(d); + int err; + + err = gc->request(gc, hwirq); + if (err) { + dev_err(&p->pdev->dev, "Can't request GPIO %d from %s\n", hwirq, + gc->label); + return err; + } dev_dbg(&p->pdev->dev, "sense irq = %d, type = %d\n", hwirq, type); -- 2.7.4