Re: [RFC] GPIO User I/O

[Rodolfo Giometti <giometti@xxxxxxxxxxxx>]

On 06/07/2020 15:35, Drew Fustini wrote:
> 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.

I see.

However my support is not designed for a general purpose board where GPIOs usage
may vary, but for final products where GPIO lines are well-defined (even if the
patch can be easily modified in order to support unregister() operations).

> 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.

As already stated in my last e-mail to Linus GPIO aggregator doesn't allow board
manufacturer to define meaningful GPIO lines within the device tree without
additional patches or by forcing users to define them by additional commands
after boot.

Why a LED should be easily and completely managed within the device-tree and a
relè, a photo-diode or any other input/output digital line should not? :-/

The driver by Pantelis Antoniou and my support does this jobs without interfere
with other GPIOs mechanisms.

I think the maintainers should seriously consider it.

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