Question about GPIO Lib

[Bill Gatliff]

Mark:

On Wed, Feb 1, 2012 at 6:32 AM, Mark Brown <broonie at sirena.org.uk> wrote:
>
> Just to expand on this a bit: lots of people would prefer not to have a
> userspace component at all due to the same hardware safety concerns that
> you have, or to have the userspace component be a driver using gpiolib
> which needs to be explicitly connected to the GPIOs.

... which I think is a spectacularly bad idea. :)

Diversion from the original theme of this thread notwithstanding, I
don't see the point in the additional complexity of implementing such
a heavy-handed lockout when it's pretty darned easy to just do a
gpio_request() in kernel space to take the pin entirely away from
users.  I do that pretty routinely, but then in the relevant
kernel-side driver I almost always offer a sysfs attribute of my own
that lets me grant users controlled access to the functionality
provided by the pin.

For example, if it's a RESET-type pin for an external chip, then I'll
have a /sys/.../assert_reset attribute such that when root writes to
it, my store() method sends a timed pulse to the physical GPIO pin. Or
not, depending on what mood the device is in at the time--- which the
driver always knows.

I won't let the user kill anyone, of course, but I WILL grant them
tools like the above to bring the platform under control and
investigate problems during hardware integration.  The productivity
improvement more than offsets the thought and code investment
required.

I have often considered a gpiolib patch that just makes sysfs
attributes read-only when kernel-side does a gpio_request(), rather
than taking the pin attributes away entirely.  That way I can have
simple tools in userspace to silently log GPIO activity for
troubleshooting.  The blocking reads that some versions of gpiolib
offer today make this work even better.



b.g.
-- 
Bill Gatliff
bgat at billgatliff.com