linux-kernel - Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdUWybAZXc2RbGMGyp4DYQZU9BS8MxXKE5Kfd+aH8+w9sA@mail.gmail.com>
Date:   Thu, 23 Mar 2017 13:03:56 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Richard Genoud <richard.genoud@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Janusz Uzycki <j.uzycki@...roma.com.pl>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

Hi Uwe,

On Thu, Mar 23, 2017 at 12:11 PM, Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> wrote:
>> Make sure to enable all drivers and subsystems you need when building
>> your kernel. That's always true. And may indeed be hard to debug (e.g. what
>> kernel options do I need to make systemd work?).
>
> It's worse here. If you forget to enable a driver the device isn't bound
> and that's obvious to diagnose. When ignoring an optional GPIO there
> might be a device that claims to work but fails to do so. (e.g. you
> write to memory, write() returns 0, but the data never landed there.)
>
>> > write(2) and close(2) succeed most of the time, too. Still it's not a
>> > good idea to not check the return value. Or let the kernel return
>> > success unconditionally.
>>
>> Writing all bytes passed in the buffer is "optional" in another sense than
>> an "optional" GPIO: you must retry the write, while you can continue if
>> an optional GPIO is not present.
>
> And that is the point. You can continue *iff* the optional GPIO is not
> present. The patch in question removes the ability to determine if that
> GPIO is present and claims it is not present.

If you forget to enable a driver/subsystem, you sometimes cannot determine
if the device is present or not neither.

Hence it boils down to "knowing" if there is a GPIO or not.
So, when can there be a GPIO?
  1. The GPIO is described in DT.
     => Not an issue, as DT GPIO implies GPIOLIB,
  2. The GPIO is described in legacy platform data.
     => The platform code should make sure GPIOLIB is selected when needed.

Issue solved?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds