linux-kernel - Re: [PATCH v2] gpio: return NULL from gpiod_get

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]

Message-ID: <CACRpkdaLgJCr+U1Rc2fv89VK7wdH=ZXi8B=QURQ2=ncRasJ-Ww@mail.gmail.com>
Date:   Tue, 14 Mar 2017 14:31:08 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Alexandre Courbot <gnurou@...il.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB
 is disabled

On Mon, Feb 13, 2017 at 2:13 AM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:

> Given the intent behind gpiod_get_optional() and friends it does not make
> sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
> work just fine without gpio so let's behave as if gpio was not found.
> Otherwise we have to special-case -ENOSYS in drivers.
>
> Note that there was objection that someone might forget to enable GPIOLIB
> when dealing with a platform that has device that actually specifies
> optional gpio and we'll break it. I find this unconvincing as that would
> have to be the *only GPIO* in the system, which is extremely unlikely.
>
> Suggested-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> ---
>
> This is a resend of a similar patch from a couple years ago.
>
> V2:

After a lot of decision angst I applied this patch, dropping Uwe's
Suggested-by since he doesn't seem to like it.

I think we should eventually return proper error codes,
but as you say: the API should be consistent first, we need
to change both the lib and the stubs to return error codes
for that, this is about something else, just keeping it consistent.

Yours,
Linus Walleij