setting udev rules for the GPIO?


9 posts
by karl101 » Thu Jun 28, 2012 7:53 pm
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
Posts: 63
Joined: Wed Jan 11, 2012 10:09 am
by andyl » Thu Jun 28, 2012 10:21 pm
Have you tried udevcontrol reload_rules and/or udevtrigger. or reboot?
Posts: 265
Joined: Tue Jan 10, 2012 11:05 am
by karl101 » Fri Jun 29, 2012 7:05 am
andyl wrote: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.
Posts: 63
Joined: Wed Jan 11, 2012 10:09 am
by katalyst » Sat Oct 20, 2012 5:34 am
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
Posts: 1
Joined: Sat Oct 20, 2012 5:28 am
by karl101 » Sun Oct 21, 2012 9:34 am
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: viewtopic.php?f=50&t=8071&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.
Posts: 63
Joined: Wed Jan 11, 2012 10:09 am
by chris.meyers.fsu » Fri Dec 14, 2012 9:50 pm
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
Posts: 27
Joined: Sat Jun 02, 2012 7:46 pm
by Duke » Sun Dec 16, 2012 9:31 pm
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
Posts: 5
Joined: Fri Dec 14, 2012 10:27 pm
by sysjay » Tue Jan 29, 2013 2:02 am
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
Posts: 3
Joined: Tue Jan 29, 2013 1:48 am
by Duke » Tue Jan 29, 2013 3:04 pm
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.
Posts: 5
Joined: Fri Dec 14, 2012 10:27 pm