Add /dev/gpiomem device for rootless user GPIO access

[Wren6991]

Currently, users need root privileges to use GPIO. This causes issues - for example, if they want to do some data logging, they will then need root permissions to edit the recorded data, and it will be put in root's home folder rather than theirs. Instead of just opening IDLE and doing import RPi.GPIO, they need to open a console, do sudo idle3 &, and close the console. etc.

This commit adds a character device, /dev/gpiomem, which maps the GPIO register page when a user mmaps it. An mmap interface is simplest at the moment because there are large and popular existing libraries which are just mmapping /dev/mem, and this means minimal code changes for the maintainers, although in the long term we would like a proper kernel-side driver rather than the existing userspace pseudo-drivers.

This allows better control of GPIO permissions, for instance there can be a gpio user group, which can give users access to GPIO without giving them the whole of physical memory.

[notro]

Do you know why these libraries want to write directly to the gpio registers instead of using the sysfs interface? Is it to speed up setting multiple gpio's in one go?

[Ferroin]

On 2015-08-20 09:13, notro wrote:

Do you know why these libraries want to write directly to the gpio
registers instead of using the sysfs interface? Is it to speed up
setting multiple gpio's in go?
I'd be willing to bet that it also has something to do with the fact
that it is easier to safely allow non-root users to map segments of
iomem than it is to give them selective access to sysfs, and also allows
(theoretically) higher performance. That and there are things out there
that are timing sensitive enough that they can't afford the overhead of
dealing with the sysfs interface.

[P33M]

There are (historical, Pi-only) tools for manipulating the GPIOs that rely on /dev/mem access. They do this for reasons of performance, mainly - the sysfs interface is slow when you want to bitbash at kHz from userspace.

As Luke says, this ends up with most things being run as root, which is Bad (tm).

This is a halfway step to deprecating userspace tools that whack registers via mmap()'ed peripheral memory spaces - at least now we can control user/group accesses and prevent arbitrary reads outside the GPIO register file (which has its own 4k segment in the bus address space) and have a low-overhead userspace code change to update these applications to use this equivalent but safer interface.

[Wren6991]

Hi Jonathan, thanks for spotting those, everything should be working now. I've only tested on a Pi 2 but raspi-gpio works with minimal changes. I've squashed in a new commit and will now go and find more Pis to test on.

As Jonathan says, the reason users are currently using /dev/mem is partly performance - there is a nice generic sysfs interface but mmapping /dev/mem allows them to go orders of magnitude faster (i.e. potentially toggling pins at MHz instead of kHz).

Also, I don't believe the sysfs interface allows setting of pullups.

[Wren6991]

Thanks Phil, I've corrected that now.

A question: currently the driver is being loaded via a device tree overlay, but if we want to make /dev/gpiomem preferred over /dev/mem then we want it to be enabled by default. After a quick discussion with @pelwell we think the gpiomem node should go in both bcm2708.dtsi and bcm2709.dtsi to avoid polluting bcm2708_common.dtsi, which is meant to be a generic hardware description, and would be one more thing that ARCH_BCM2835 would have to patch out.

Thoughts?

[pelwell]

(Context: @notro has a pending PR to include bcm2708_common.dtsi from bcm2835.dtsi)

[Wren6991]

Squashed into one commit. What do people think?

[pelwell]

The concept doesn't really fit with the spirit of Device Tree (including the GPIO block twice, giving it a different compatible string to cause a particular driver to be loaded) but we are doing it to allow the various user-space GPIO libraries to be cleaned up a bit by not requiring root privilege, in a way that doesn't require changes to the board support code or to /etc/modules.

Given the above, I'm happy with it.

[Wren6991]

I totally agree, but it's a positive step away from the current state of everyone running as root and mapping /dev/mem willy nilly.

I've sent a pull request to raspi-gpio and a patch to the maintainer of RPi.GPIO to add support for /dev/gpiomem.

[Wren6991]

@popcornmix what do you think?

[popcornmix]

Yes, I'm okay with this. It is ugly, but less so than running python as root to use gpio libraries.

[pelwell]

Luke, do you want to make any changes following popcornmix's comments?

[Wren6991]

Thanks for that Dom, I've removed those useless gotos. I'm happy if you are!

[pelwell]

drivers/char/broadcom/bcm2835-gpiomem.c: In function "bcm2835_gpiomem_probe":
drivers/char/broadcom/bcm2835-gpiomem.c:204:2: warning: format "%x" expects argument of type "unsigned int", but argument 3 has type "long unsigned int" [-Wformat=]
  dev_info(inst->dev, "Initialised: Registers at 0x%08x",
  ^

[Wren6991]

diff --git a/drivers/char/broadcom/bcm2835-gpiomem.c b/drivers/char/broadcom/bcm2835-gpiomem.c
index 0d46050..0085e13 100644
--- a/drivers/char/broadcom/bcm2835-gpiomem.c
+++ b/drivers/char/broadcom/bcm2835-gpiomem.c
@@ -201,7 +201,7 @@ static int bcm2835_gpiomem_probe(struct platform_device *pdev)
                inst->gpio_regs_phys = GPIO_BASE;
        }

-       dev_info(inst->dev, "Initialised: Registers at 0x%08x",
+       dev_info(inst->dev, "Initialised: Registers at 0x%08lx",
                inst->gpio_regs_phys);

        return 0;

Wow. Sorry, Phil.

[P33M]

This thread's been blowing up my email notifications for the last four hours. Go to bed, Luke.

[dotdoom]

Any chance /dev/gpiomem gets PWM control registers range (base + 0x200000)?

[popcornmix]

Unlikely. If we add PWM, then why not clock manager, or dma, or interrupt any other peripherals.
This was reluctantly added as teaching resources were using python libraries to access gpio and the requirement for running as root was setting a bad example.
We don't want to extend this to allow more hacky peripheral drivers from userland. I suspect any pwm accesses should go through a proper kernel driver.

[BTBlueSkies]

I'd like to say thanks for the new /dev/gpiomem addition and add an user comment. While I understand the last comment about if you add PWM, then why not clock manager or dma, etc.. I'd like to add that as a user of this board, when I envision the applications for the board, I am mostly thinking of the functions supplied on the GPIO header. The SPI, the I2C, the PWM and so forth. So far it has been burdensome and hard to properly make use of these features and keep good security practices intact.

I'd vote that at a minimum, raw access via GPIOMEM should be maintained and extended to the scope of the GPIO pinmap. Performance is often key, especially since these products are often presented as good for robotics etc; thus degrading performance via a layer of kernel modules such as sysfs is not only going to not serve the vision of the product, it will be a disservice to the user base.

Just a friendly 2 cents. Smiles.

[jgarzagu]

I support what BTBlueSkies says. SPI, I2C, PWM and GPIO are the main peripherals most people use for hardware projects. We can access SPI and I2C with the proper drivers but we are missing PWM. If we could get PWM registers that would be awesome. I can help writing/modifying the driver, but because this driver is already supported in the Raspbian image I would prefer that the change was done into this driver.

Thanks.

[Wren6991]

This patch probably won't be updated, because it is a hack. It solved an
immediate problem but is not a final answer - userspace pseudo-drivers are
not the way to do things. A proper driver for GPIO + PWM would be better
long-term than userspace poking, so if you have any suggestions for this
then that would be useful.

If you want to patch this driver yourself, you should just be able to add
the PWM page address to gpiomem.c, as long as nothing else is on that page.

On Mon, May 16, 2016 at 3:37 AM, Jorge Garza notifications@github.com
wrote:

I support what BTBlueSkies says. SPI, I2C, PWM and GPIO are the main
peripherals most people use for hardware projects. We can access SPI and
I2C with the proper drivers but we are missing PWM. If we could get PWM
registers that would be awesome. I can help writing/modifying the driver,
but because this driver is already supported in the Raspbian image I would
prefer that the change was done into this driver.

Thanks.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1112 (comment)

[bennuttall]

We've just added a C library called pigpio which runs as a daemon. It's a good way of doing GPIO in any language (rather than writing to /dev/mem or gpiomem), as you can just communicate using sockets, and the actual GPIO stuff is handled for you (and saves you from reimplementing it all).

I assume the likes of RPi.GPIO will still do it using gpiomem.

I don't know whether pigpio can be pushed all the way to the kernel, but its presence in Raspbian provides a method of doing GPIO without this hack.