linux-kernel - Re: [RFC PATCH 3/5] gpio: gpiolib: Add chardev support for maintaining GPIO values on reset

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdZzr3JHo=AEZejXn0nw0mZo02OWFmmTiUBjgr+bH+NOAw@mail.gmail.com>
Date:   Tue, 31 Oct 2017 10:59:55 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andrew Jeffery <andrew@...id.au>
Cc:     Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Michael Welling <mwelling@...cinc.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Joel Stanley <joel@....id.au>,
        Ryan Chen <ryan_chen@...eedtech.com>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        patches@...nsource.cirrus.com,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        OpenBMC Maillist <openbmc@...ts.ozlabs.org>,
        linux-aspeed@...ts.ozlabs.org
Subject: Re: [RFC PATCH 3/5] gpio: gpiolib: Add chardev support for
 maintaining GPIO values on reset

On Thu, Oct 26, 2017 at 2:05 AM, Andrew Jeffery <andrew@...id.au> wrote:

> I feel that taking this argument to its logical conclusion leads to
> never exporting any GPIOs to userspace and doing everything in the
> kernel.

That is very much how I feel about things anyways.
In a recent presentation:
https://dflund.se/~triad/papers/GPIO-for-Engineers-and-Makers.pdf

I had the following text:

The Rules of Linux Userspace GPIO
1. You do not access GPIOs from userspace
2. YOU DO NOT ACCESS GPIOS FROM USERSPACE
3. Read Documentation/gpio/drivers-on-gpio.txt
4. Use the character device

> If userspace has exported the GPIO and is managing its state,
> then it can *already* cause very weird hardware behaviour if set wrong.
> The fact that userspace is controlling the GPIO state and not the
> kernel already says that the kernel doesn't know how to manage it, so
> why not expose the option for userspace to set the persistence, given
> that it should know what it's doing?

People do need to access GPIOs from userspace for things
like one-off makerspace projects, relays on factory lines,
fire alarms, door openers etc etc.

One-off projects is fine, the user likely has an idea about the
whole system that is comprehensive. They use the random
raspberry Pi (etc) development board for this. OK.

When we are talking about adding GPIO in mass-market goods
such as phones and tablets and laptops userspace GPIO
access become more and more dubious.

Yours,
Linus Walleij