Re: [RFC] GPIO User I/O

[Rodolfo Giometti <giometti@xxxxxxxxxxxx>]

On 06/07/2020 15:43, Linus Walleij wrote:
> Hi Rodolfo!

Hi. :)

> thanks for your mail.
> 
> On Mon, Jul 6, 2020 at 2:19 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote:
> 
>> 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
> 
> This interface is problematic because it extends the sysfs ABI which is
> obsolete. This is why the documentation of this ABI has been moved to
> Documentation/ABI/obsolete/sysfs-gpio  for many years.

This support is not part of CONFIG_GPIO_SYSFS; it just uses the sysfs to work.

> The sysfs approach has several problems which are summarized like
> this in the commit where it was introduced:

I see, but my solution is just for having an easy-to-use way to get access to
meaningful GPIOs the board manufacturer defined for some specific usage during
the board design. It's not generic as gpio-sysfs.

> Another thing that is not mentioned here is that when a character
> device is opened it is automatically closed if a process crashes,
> which means that kernelspace can do clean-ups and reference counting
> and making the lines available to other consumers (like if you
> restart the program).

In this case there is nothing to release nor clean up since each line has a
fixed name, usage and it can be used as input or output without modifications.

> With Geert's GPIO aggregator userspace and device tree can conjure
> special per-usecase gpio chips as pointed out by Drew: this is
> very useful when you want some kernel-managed yet
> usecase-specific GPIO lines in a special "container" chip.
> To me this is the best of two worlds. (Kernelspace and userspace.)

Maybe this is the "best of two worlds" as you say but the problem is that board
manufactures need a way to well-define how a GPIO line must be used for within
the device-tree and without the need of patches! In this point of view neither
the "driver_override" way nor adding a compatible value to
gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
board!). That's why at the moment they prefer not specify these GPIO lines at
all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
simple...

By using my solution each board manufacturer can specify meaningful GPIO lines
directly within the device-tree, then users can use it via the "line" property
or just use the new chrdev interface for better performances.

Also my solution allows developers to manage these lines without any external
programs but just using cat&echo. This is _very_ useful when your embedded
system has a very tiny rootfs!

My two cents. :)

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@xxxxxxxxxxxx
Linux Device Driver                          giometti@xxxxxxxx
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti