lkml.org 
[lkml]   [2008]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: userspace GPIO access (WAS: [patch/rfc 2/4] pcf875x ...)
Date
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



\
 
 \ /
  Last update: 2008-04-05 06:09    [from the cache]
©2003-2011 Jasper Spaans