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: <20170323155519.GB9460@dtor-ws>
Date:   Thu, 23 Mar 2017 08:55:19 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        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

On Thu, Mar 23, 2017 at 12:11:06PM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Thu, Mar 23, 2017 at 11:20:39AM +0100, Geert Uytterhoeven wrote:
> > But having the error breaks setups where the GPIO is optional and does
> > not exist.
> 
> so the right way forward is to check harder in the situation where
> -ENOSYS was returned before to determine if there is really no GPIO to
> be used. "Oh, there are hints that there is no GPIO (GPIOLIB=n), so lets
> assume there isn't." is wrong.
> 
> Can we please properly fix the problem instead of papering over it?

I think I once already said what would need to _attempt_ to fix it
"properly". You would need to implement custom parsing of ACPI tables in
GPIOLIB (what if they disable ACPI by mistake?), do the same for OF,
call board's manufacturer hotline to ensure that they indeed did not
forget to describe GPIOs, etc, etc.

Or you could trust that person responsible for selecting kernel
configuration has a clue, and if GPIOLIB is disabled it was disabled for
a reason.

-- 
Dmitry