setting udev rules for the GPIO?

[karl101]

Hello,
Using Debian "wheezy" I have been trying to set the group permission for /sys/class/gpio to dialout. This is to avoid having to run my programs that use the GPIO as root. I have been trying to set the permissions with udev rules with a notable lack of success, I can identify the device:

Code: Select all

 $ udevadm info --path=/sys/class/gpio --attribute-walk

  looking at device '/class/gpio':
    KERNEL=="gpio"
    SUBSYSTEM=="subsystem"
    DRIVER==""

so, after reading the manual and various web pages, I setup a rule as /etc/udev/rules.d/91-gpio.rules with this:

Code: Select all

KERNEL=="gpio*", MODE:="0660", GROUP:="dialout"

but the permissions on the directory remain as root:root. I have tried a variety of rules but with no joy.

Any ideas? Am I doing this the wrong way?
Thanks
Karl

[andyl]

Have you tried udevcontrol reload_rules and/or udevtrigger. or reboot?

[karl101]

Have you tried udevcontrol reload_rules and/or udevtrigger. or reboot?

those two commands have been replaced with udevadm:
$ sudo udevadm control --reload-rules
$ sudo udevadm trigger --verbose

no change is made when they're run, and these don't work either:
$ sudo /etc/init.d/udev restart
rebooting the pi.

Karl.

[katalyst]

I started experimenting by changing ownership to the /sys/class/gpio tree by placing this in my rc.local:

Code: Select all

chown -R pi:pi /sys/class/gpio

Which obviously allows you to export a gpio pin.
I ran into the same issue of root ownership of the gpioX nodes that get created when a gpio pin is exported, preventing me from changing it's direction, or value.

After a while, I figured out the right udev incantation, and this is what I have in my udev rules file (99-gpio.rules):

Code: Select all

SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chown -R pi:pi /sys%p'"

This works!

The nodes are accessed by:
/sys/devices/virtual/gpio/gpioX/direction
/sys/devices/virtual/gpio/gpioX/value
etc...

It has udev change the permissions to the dynamically generated gpioX files, allowing access without sudo, or similar techniques.
You can easily substitute other commands to change the permissions, instead of changing the ownership.

Providing access to www-data, for example, allows direct reading/writing with PHP file commands to manipulate the gpio states, which was my goal.

Just another way to have fun with the Raspberry Pi. Thanks Eben!

I hope that someone finds this helpful.

Dave

[karl101]

Hello Dave,
Yes that works, I can see the ownership change in the /sys/devices/virtual/gpio directory. This is very useful.

However, as the man says here: http://www.raspberrypi.org/phpBB3/viewt ... &start=425 "the goalposts have moved!". The quest is to get the python RPi.GPIO module running without having to escalate to root privileges, this now uses /dev/mem to access the GPIO.

Code: Select all

 $ python try_pi.py
Traceback (most recent call last):
  File "try_pi.py", line 7, in <module>
    import RPi.GPIO as GPIO
RPi.GPIO.SetupException: No access to /dev/mem.  Try running as root!

Drat!, Foiled!.

But your udev rule is staying in, I may have a go a some C++ programming in the future and that'll make life a little easier.
Karl.

[chris.meyers.fsu]

Code: Select all

SUBSYSTEM=="subsystem", KERNEL=="gpio",  ACTION=="add", PROGRAM="/bin/sh -c 'chown -R pi:pi/sys%p'"

To test the above run:

Code: Select all

sudo udevadm test --action=add /class/gpio

This should output something like the below:

Code: Select all

udev_rules_apply_to_event: PROGRAM '/bin/sh -c 'chown -R pi:pi /sys/class/gpio'' /etc/udev/rules.d/99-input.rules:1
udev_event_spawn: starting '/bin/sh -c 'chown -R pi:pi /sys/class/gpio''
spawn_wait: '/bin/sh -c 'chown -R pmp:pmp /sys/class/gpio'' [2851] exit with return code 0

Then finally check the results:

Code: Select all

ls -al /sys/class/gpio

Should look like the below:

Code: Select all

pi@raspberrypi /etc/udev/rules.d $ ls -al /sys/class/gpio
total 0
drwxr-xr-x  2 pmp  pmp     0 Dec 14 16:45 .
drwxr-xr-x 30 root root    0 Dec 14 16:43 ..
--w-------  1 pmp  pmp  4096 Dec 14 16:45 export
lrwxrwxrwx  1 pmp  pmp     0 Dec 14 16:45 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w-------  1 pmp  pmp  4096 Dec 14 16:45 unexport

[Duke]

Sadly, nothing here worked for me so I got a bit frustrated and kinda forced the issue.

This is my /etc/udev/rules.d/91-gpio.rules

Code: Select all

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio; chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio; chmod -R 770 /sys/devices/virtual/gpio'"

It's a bit dirty but workes fine for me.
For some reason users need execute rights on at least /sys/class/gpio/export so I set the filemode to 770.
I also ommited the ACTION="add" filter so it runs everytime a gpio is (un)exported.

Duke

[sysjay]

Hi.. i am working on using gpio for a arduino to raspberry pi application. I have been working on access gpio on pi --- root works great. I have bee working on similar udev rules to grant user access.

This may be a dumb question, but why can't gpio be mapped to a normal /dev type device and then managed similarly?

Thanks..

Jay

[Duke]

Even if it would be created in /dev, the udev rules still would be the same, just the path would have changed.
But I don't know whats the real reason for not putting it in /dev.

[MikeDK]

Hi!

Lately I tried the suggestions from this thread to enable non-root users to access the gpios ... but none of them were working as expected ... the 'dirty' one was working, but hat side effects...

I did some experimenting, and I found a perfect solution for me, and want to share it with you all ... here it is:

Code: Select all

SUBSYSTEM=="gpio", KERNEL=="gpiochip*", ACTION=="add", PROGRAM="/bin/sh -c 'chown root:gpio /sys/class/gpio/export /sys/class/gpio/unexport ; chmod 220 /sys/class/gpio/export /sys/class/gpio/unexport'"
SUBSYSTEM=="gpio", KERNEL=="gpio*", ACTION=="add", PROGRAM="/bin/sh -c 'chown root:gpio /sys%p/active_low /sys%p/direction /sys%p/edge /sys%p/value ; chmod 660 /sys%p/active_low /sys%p/direction /sys%p/edge /sys%p/value'"

The first rule will be used when the gpiochip0 will be loaded and opens access to the export and unexport files.
The second rule is used when a gpio pin is exported.
A user will have to be member of the group "gpio".

I chose to specify the files explicitly to reduce side effects

I hope this works for other people too

Regards,
MikeDK

[ftheile]

For the new GPIO chip API, I created the following udev rule in /etc/udev/rules.d/gpio.rules to put all GPIO chips into group 'gpio':

Code: Select all

KERNEL=="gpiochip*", GROUP="gpio"