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

[Trent Piepho <tpiepho@freescale.com>]

On Fri, 4 Apr 2008, David Brownell wrote:
>
> - 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.

This was intentional.  When you're developing said kernel drivers, or
connecting hardware they're supposed to drive, it's very handy to be able
to set and read the GPIOs from userspace.  At least, when writing a
gpiolib driver and code that used gpiolib, I found this ability very
useful, so I thought other developers might as well.

I suppose one could make the sys files read-only once a kernel driver
allocates a gpio.  But it would be nice to have the ability to make them
writable, if one really wants that.

>   (Plus it won't work on most built-in GPIOs, since
>   they by and large don't have parent devices.)

Couldn't they always add one?  My GPIO driver is part of the CPU/SoC, and
it has a device node.  It's pretty easy to add a platform device, and
probably cleaner than not associating a device with the gpio driver. 
>From my understanding of sysfs, it seems any sysfs based approach has to
be based on a device.

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

Suppose I took the code I had, and make the label file writable?  Writing
to it allocates the gpio with the written label?  That would be
relatively simple to add.  Is there any reason why the GPIOs should
appear in sysfs by default?  They are devices, and most other devices
appear in sysfs.

> Plus, there should be some way to cause gpio_free() too.

Write a blank label?  Too bad one can't "rm" sysfs files, that would be a
neat way to trigger stuff.  I can see it used to hot-unplug a pci device,
just delete the slot.