Mark: 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 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 b...@billgatliff.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
