sysfs-gpio: use new /sys/bus/gpio/devices/gpiochipN, also listed as /dev/gpiochipN

[maruel]

Ported from https://github.com/google/periph/issues/371

It's the "new" GPIO API for linux kernels above 4.8, based on ioctl on a single handle instead of having to open multiple handles. There isn't a need to support older kernels anymore so we should just switch over.

[maruel]

I failed to find proper documentation. Sadly, there's zero reference to PWM in libgpiod.

[gsexton]

@maruel I've looked over the linked ticket, but don't understand what's yet to be done. If you could give me some idea of what's needed, I could give it a go.

[maruel]

@gsexton In periph.io/x/host/v3/sysfs, the function driverGPIO.Init() opens the directories in /sys/class/gpio/gpiochip*. This needs to be changed to use /sys/bus/gpiochip*. There's more to it than just the discovery since the way to access each gpio is a bit different.

Copying from the original issue:

It's the "new" GPIO API for linux kernels above 4.8, based on ioctl on a single handle instead of having to open multiple handles. Now [in 2019] that devices are using later kernels (Raspbian is on 4.14), periph should enable the use of this interface when available, and fallback with the current code on older kernels.

The primary rationale is that it enables pull resistors via the constants GPIOLINE_FLAG_OPEN_DRAIN and GPIOLINE_FLAG_OPEN_SOURCE. It also enables support for reading and writing multiple lines at once. This would have many uses but the periph gpio API currently doesn't make this use-case easy to implement, so multi-pin synchronized I/O requires more thoughts.

Refs:

• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/gpio.h includes the definitions
• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio/lsgpio.cis an example.
• libgpiod at https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/?h=v2.1.1 is the "official" user space library to wrap the calls, but it's not necessary.

[gsexton]

@maruel I've been working on this using the v2 IOCTL calls. I've got single-pin working, and I'll work on a multi-pin implementation. Now that I know what I'm doing, it shouldn't be really hard. I can see for a fair number of use cases where being able to write multiple pins would be very handy. I wrote my own implementation of the MCP23008 to handle multiple pins in one call.

Anyhow, I should have a preliminary PR in two weeks or so.