Question about GPIO Lib

[Bill Gatliff]

Bruce:

On Mon, Jan 30, 2012 at 6:06 PM,  <Bruce_Leonard at selinc.com> wrote:
> Bill Gatliff <bgat at 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
bgat at billgatliff.com