Question about GPIO Lib

[Mark Brown]

On Wed, Feb 01, 2012 at 09:56:45AM -0600, Bill Gatliff wrote:
> 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

Well, it's about the default - some people feel a lot safer blocking
everything by default and then enabling particular signals they want
userspace to control.  That default is more annoying for people who want
to do debug but a lot less controversial in terms of things possibly
going wrong.

> 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.

That's a useful idea.