Re: [RFC] GPIO User I/O

[Drew Fustini <drew@xxxxxxxxxxxxxxx>]

On Mon, Jul 06, 2020 at 02:19:49PM +0200, Rodolfo Giometti wrote:
> Hello,
> 
> at the moment if a developer wishes to use a GPIO as output or input with a well
> defined name from userspace via the sysfs interface he/she can use,
> respectively, the gpio-leds or gpio-uinput devices. However, IMHO, this is not
> the best nor a proper way to do it, that's why I'm here to propose this really
> simple interface named GPIO_UIO.
> 
> That's why I wrote the attached patch (for kernel 4.19) which it's just a
> proposal, and the purpose of this message is to collect feedback about this
> solution. Of course I'll be happy to port it for latest kernel release and
> complete it with all requested documentation and needed modifications, but I'll
> do it only if this patch has some changes to be accepted by GPIO subsystem's
> maintainers. :)
> 
> For the moment here is how it works:
> 
> 1) The patch is activated by the configuration entry CONFIG_GPIO_UIO.
> 
> 2) In the device-tree the developer defines all board's GPIO lines with their
> names and mode of functioning:
> 
> +       gpio_uio {
> +               compatible = "gpio-uio";
> +
> +               bypass0 {
> +                       gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
> +                       mode = "out-low";
> +               };
> +
> +               bypass1 {
> +                       gpios = <&gpiosb 11 GPIO_ACTIVE_HIGH>;
> +                       mode = "out-low";
> +                       label = "bypass-1";
> +               };
> +        };
> 
> Property "mode" can be "asis", "input", "out-low", etc. and the property label
> can be used in case the GPIO line's name should be different from the node's name.
> 
> 3) At boot the GPIO lines are added:
> 
> [    2.398902] gpio-uio bypass0: line added
> [    2.423558] gpio-uio bypass-1: line added
> 
> 4) Then users will find a new class with entries, one for each new line:
> 
> # ls /sys/class/gpio-uio/
> bypass-1  bypass0
> 
> 5) By using the attribute "line" the users can get or set the line status
> 
> # cat /sys/class/gpio-uio/bypass-1/line
> 0
> # echo 1 > /sys/class/gpio-uio/bypass-1/line
> # cat /sys/class/gpio-uio/bypass-1/line
> 1
> 
> 6) Developers can monitor the GPIO lines via debugfs as for kernel modules:
> 
> # cat /sys/kernel/debug/gpio
> gpiochip1: GPIOs 446-475, parent: platform/d0018800.pinctrl, GPIO2:
>  gpio-457 (                    |bypass-1            ) out lo
> 
> gpiochip0: GPIOs 476-511, parent: platform/d0013800.pinctrl, GPIO1:
>  gpio-479 (                    |cd                  ) in  hi IRQ
>  gpio-480 (                    |vcc_sd1             ) out lo
>  gpio-486 (                    |bypass0             ) out lo

This is similar to an out-of-tree driver we use in the kernel build for
our BeagleBoard.org Debian images called gpio-of-helper [0].

It is a DT based driver created by Pantelis Antoniou back in 2013.  It
allows our downstream BeagleBoard.org dts files to describe the gpio
lines that will be controlled from userspace.  We failed to get the
driver upstream back then, and it has remained out-of-tree since.

Currently, I am trying to shrink our out-of-tree patches [1] so we can
eventually get our BeagleBoard.org kernel builds on to mainline. Thus
coming up with a mainline solution for this is important to me. I was to
chat virtually last week with Bart [2], Geert and Linus and it does seem
like the new GPIO aggregator [3] could address this use case. I need to
do some experimentation to understand how that would work.

Regards,
Drew

[0] https://github.com/beagleboard/linux/blob/5.4/drivers/gpio/gpio-of-helper.c
[1] https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-5.4.y/patches
[2] https://static.sched.com/hosted_files/ossna2020/67/Linux%20GPIO-Evolution%20and%20Current%20State%20of%20the%20User%20API.pdf
[3] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html