On Wed, Feb 01, 2012 at 09:56:45AM -0600, Bill Gatliff wrote: > On Wed, Feb 1, 2012 at 6:32 AM, Mark Brown <broo...@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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
