Re: [PATCH] pinctrl: sh-pfc: Let gpio_chip.to_irq() return -ENXIO on error

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Fri, Apr 29, 2016 at 9:24 AM, Geert Uytterhoeven
<geert+renesas@xxxxxxxxx> wrote:

> Currrently the gpio_chip.to_irq() callback returns -ENOSYS on error,
> which causes bad interactions with the serial_mctrl_gpio helpers.
>
> mctrl_gpio_init() returns -ENOSYS if GPIOLIB is not enabled, which is
> intended to be ignored by its callers. However, ignoring -ENOSYS when it
> was caused by a gpiod_to_irq() failure will lead to a crash later:
>
>     Unable to handle kernel paging request at virtual address ffffffde
>     ...
>     PC is at mctrl_gpio_set+0x14/0x78
>
> Fix this by returning -ENXIO instead.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> ---
> Is -ENXIO the right error code?

I would say that whatever the generic helpers in drivers/gpio/gpiolib.c
returns should be the norm. However the guy who wrote them (me)
isn't very smart either. It looks like so:

static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset)
{
        return irq_find_mapping(chip->irqdomain, offset);
}

That returns 0 (NO_IRQ) on failure.

And as you say:

>   - Drivers that call irq_find_mapping(), irq_create_mapping(), or
>     irq_create_fwspec_mapping() return zero!  This also applies to the
>     core helper gpiochip_to_irq().

Zero means NO_IRQ.

Reminder:
http://lwn.net/Articles/470820/

What we should do is patch all drivers to return 0 on failure, and
patch any consumers like mctrl_gpio_init() to handle that correctly.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html