linux-kernel - Re: [PATCH] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 10 Jun 2020 13:18:06 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org list" <linuxppc-dev@...ts.ozlabs.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>
Subject: Re: [PATCH] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs

Hi Christophe!

On Sat, Jun 6, 2020 at 9:30 AM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:


>                 gpiod = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
>
> -               if (gpiod) {
> +               if (!IS_ERR_OR_NULL(gpiod)) {
>                         if (i == GPIO_RTS || i == GPIO_DTR)
>                                 ret = gpiod_direction_output(gpiod, 0);
>                         else

This code, and the way descriptors are used in the driver leads
me to believe that the right solution is to use the optional
call with a hard error check:

gpiod = devm_gpiod_get_index_optional(...);

if (IS_ERR(gpiod))
    return PTR_ERR(gpiod);

if (gpiod) {
... followed by the old code ...

This makes sure that the array member is left NULL if there is no
GPIO on this line, and all other errors, such as -EPROBE_DEFER
which currently absolutely does not work, will lead to us properly
exiting with an error.

Yours,
Linus Walleij