linux-kernel - Re: userspace GPIO access (WAS: [patch/rfc 2/4] pcf875x ...)

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: <200804042105.47687.david-b@pacbell.net>
Date:	Fri, 4 Apr 2008 21:05:47 -0700
From:	David Brownell <david-b@...bell.net>
To:	Ben Nizette <bn@...sdigital.com>
Cc:	Trent Piepho <tpiepho@...escale.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Mike Frysinger <vapier.adi@...il.com>
Subject: Re: userspace GPIO access (WAS: [patch/rfc 2/4] pcf875x ...)

On Thursday 03 April 2008, Ben Nizette wrote:
> David, you're kinda the gatekeeper here; any input from you on which
> approach is to be preferred, essential features etc?

I won't much care about /dev/... vs /sys/... though I'd
probably have used sysfs myself (just because it's much
simpler and doesn't need to imply mdev/udev and classes).

The configuration part of each driver bothers me:

 - Mike's simple_gpio requires manual kernel config
   to set up the platform_device nodes ... and thus
   rules out the first usage scenarios I ever heard
   of for such a userspace mechanism.

 - Trent's gpio_class exposes all GPIOs, even ones
   that are claimed by kernel drivers ... and thus
   makes it easy to clobber kernel driver state.
   (Plus it won't work on most built-in GPIOs, since
   they by and large don't have parent devices.)

What I'd like to see is userspace config commands to
cause the gpio_request() ... *maybe* something like

    echo 42 foo 0 > .../gpio_config

	... causing error-checked versions of:

    gpio_request(42, "foo")
    gpio_direction_output(42, 0)

	... then some .../gpio42 file, read/write, appears

and

    echo 84 bar in > .../gpio_config

	... causing error-checked versions of:

    gpio_request(84, "bar")
    gpio_direction_input(84)

	... then some .../gpio84 file, read-only, appears

Though arguably the label could just always be "userspace"
(it's mostly for /sys/kernel/debug/gpio), and the default could
be to configure as an input (unless an output value was given).
Plus, there should be some way to cause gpio_free() too.

A potential advantage of the /dev/... node approach would be
that it's easier to support an IRQ-backed poll() mechanism
for inputs.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/