Question about GPIO Lib

Question about GPIO Lib

[Bruce_Leonard]

(This time with a subject line, sorry)

Hi,

I'm using the 3.0.3 kernel on an MPC8308 and have turned on GPIO support 
(CONFIG_GPIOLIB = Y) because the SPI sub-system needed to use it for the 
GPIO pin I'm using as a CS to a NvRAM part.  I also have some jumpers on 
the processor GPIO pins and I thought it would be really slick to use the 
built in GPIO support in the kernel rather than roll my own driver to read 

five pins.  So I've got GPIO sysfs support turned on (CONFIG_GPIO_SYSFS = 
Y) and everything shows up in /sys/class/gpio and works as advertised. 
Really nice.

The problem is we've got a number of other things hooked up to the GPIO 
pins that it would be very bad if someone from user space played with 
them, like our FPGA configuration pin.  Some one toggles that and our box 
goes stupid.  So what I'm wondering is if there's a way, preferably via 
the device tree, to limit the GPIOs that GPIO Lib exposes to user space?

I tried the following in my device tree without success:

      gpio1: gpio@c00 {
         #gpio-cells = <2>;
         device_type = "gpio";
         compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
         reg = <0xc00 0x18>;
         interrupts = <74 0x8>;
         interrupt-parent = <&ipic>;
         gpio-controller;
         gpios = <&gpio1 0 0
                  &gpio1 1 0
                  &gpio1 2 0
                  &gpio1 3 0
                  &gpio1 4 0
                  &gpio1 5 0
                  &gpio1 6 0>;
      };

I also thought maybe a separate child node of the gpio1 node, but I think 
it would require a "compatible" attribute which would mean a driver to 
bind it to, and the whole point is to avoid writing a driver if someone 
else has already got something that will work.

Thanks.

Bruce

Re: Question about GPIO Lib

[Bill Gatliff]

Bruce:

On Fri, Jan 27, 2012 at 5:31 AM,  <Bruce_Leonard@selinc.com> wrote:
>
> The problem is we've got a number of other things hooked up to the GPIO
> pins that it would be very bad if someone from user space played with
> them, like our FPGA configuration pin. =A0Some one toggles that and our b=
ox
> goes stupid. =A0So what I'm wondering is if there's a way, preferably via
> the device tree, to limit the GPIOs that GPIO Lib exposes to user space?

Sounds like you DON'T want to merely export that GPIO pin to userspace.

If you have anything in kernel space doing a gpio_request() on that
pin, it won't be exportable to userspace anyway.  Regardless, you are
probably better off implement a DEVICE_ATTR that, in its store()
method, treads lightly on said pin.  And then do a gpio_request() in
kernel space so that users can't ever see the pin directly.

Just my $0.02.


b.g.
--=20
Bill Gatliff
bgat@billgatliff.com

Re: Question about GPIO Lib

[Bruce_Leonard]

Bill,

Bill Gatliff <bgat@billgatliff.com> wrote on 01/27/2012 10:42:57 AM:

> 
> On Fri, Jan 27, 2012 at 5:31 AM,  <Bruce_Leonard@selinc.com> wrote:
> >
> > The problem is we've got a number of other things hooked up to the 
GPIO
> > pins that it would be very bad if someone from user space played with
> > them, like our FPGA configuration pin.  Some one toggles that and our 
box
> > goes stupid.  So what I'm wondering is if there's a way, preferably 
via
> > the device tree, to limit the GPIOs that GPIO Lib exposes to user 
space?
> 
> 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 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.

> If you have anything in kernel space doing a gpio_request() on that
> pin, it won't be exportable to userspace anyway.  Regardless, you are
> probably better off implement a DEVICE_ATTR that, in its store()
> method, treads lightly on said pin.  And then do a gpio_request() in
> kernel space so that users can't ever see the pin directly.
> 
> Just my $0.02.
> 

If I understand this correctly you're basically saying that gpiolib is a 
waste of time and I should just write my own driver?

Bruce

Re: Question about GPIO Lib

[Bill Gatliff]

Bruce:

On Mon, Jan 30, 2012 at 6:06 PM,  <Bruce_Leonard@selinc.com> wrote:
> Bill Gatliff <bgat@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. =A0I don't want or need to access any of the exported pins from ker=
nel
> space and I don't want user space to access any pin not explicitly called
> out in the device tree. =A0I 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.
--=20
Bill Gatliff
bgat@billgatliff.com

Re: Question about GPIO Lib

[Bruce_Leonard]

Bill,

Bill Gatliff <bgat@billgatliff.com> wrote on 01/31/2012 08:39:05 AM:
> 
> I misunderstood your message, then.  I was thinking that you were
>

No worries, I frequently misunderstand myself :)  Thanks for taking the 
time to respond, I appreciate it.
 
> 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

Okay, that's more or less the point I had gotten to myself.  My first 
linux project I just wrote everything myself and on this latest one I've 
been making a concerted effort to utilize existing services within the 
kernel.  This looked (and still does) like a good candidate, I guess I 
just need to wrap a little bit of extra around it.

Thanks!

Bruce

Re: Question about GPIO Lib

[Mark Brown]

On Tue, Jan 31, 2012 at 10:39:05AM -0600, Bill Gatliff wrote:

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

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.

Re: Question about GPIO Lib

[Bill Gatliff]

Mark:

On Wed, Feb 1, 2012 at 6:32 AM, Mark Brown <broonie@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
bgat@billgatliff.com

Re: 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@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.