Bruce: On Mon, Jan 30, 2012 at 6:06 PM, <bruce_leon...@selinc.com> wrote: > Bill Gatliff <b...@billgatliff.com> wrote on 01/27/2012 10:42:57 AM: >> Sounds like you DON'T want to merely export that GPIO pin to userspace. >> > > Well, yes I do want to just export to userspace
I misunderstood your message, then. I was thinking that you were already using certain pins in kernel space, and didn't want THOSE pins exported to userspace due to the risks that users might invoke them and cause Bad Things to happen. > I just want to restrict > the pins that get exported to only those that are defined in the device > tree. I don't want or need to access any of the exported pins from kernel > space and I don't want user space to access any pin not explicitly called > out in the device tree. I want it to behave like gpio-leds only with > input as well as output capabilities. I glanced at gpiolib.c, and I don't immediately see a way to achieve this with the current code. Again, you could get the same net effect by doing a gpio_request() in kernel space on the pins you DON'T want exported, which would prevent those pins being exportable. But that's still different from what you are actually asking for. > If I understand this correctly you're basically saying that gpiolib is a > waste of time and I should just write my own driver? I'm DEFINITELY not saying that gpiolib is generally a waste of time! :) I'm just saying that, sadly, in many ways gpiolib is still a work-in-progress. The userspace component has been somewhat controversial in general over the years, and definitely lacks several key features in addition to the one you are asking for. Since I know others will ask :), note that the userspace component won't give you a direction attribute for pins whose directions cannot be changed from userspace. That's a pretty important omission, since it prevents me from conveniently verifying (apart from debugfs, I mean) that a pin is in fact configured in the direction I want it to be. Whether I can change its direction is a different issue entirely. Another omission that has struck me over the years is that it's not straightforward for gpio_chip authors to add custom attributes in sysfs for either the chip itself, or for the pins the chip exports. Within /sys/class/gpio/gpio<N>/ I mean. But even in its current state, gpiolib is awesome. Maybe someday I or someone else will find time to make it awesomer. :) b.g. -- Bill Gatliff b...@billgatliff.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev