Re: [RFC v2 GPIO lines [was: GPIO User I/O]

[Rodolfo Giometti <giometti@xxxxxxxxxxxx>]

On 16/07/2020 15:38, Linus Walleij wrote:
> On Tue, Jul 14, 2020 at 4:01 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote:
> 
>> I see... however attached is a new version of my proposal patch
> 
> I looked a bit at this!
> 
> IIUC the idea is a "new" sysfs interface that does not require the exporting
> etc used by the current "old" sysfs interface. Instead of poking around in
> sysfs to export lines we do that from the device tree.

Yes.

> It also does not use any global GPIO numbers which would be my other
> main concern.

Exactly, the idea is to have "names" that describe the IO lines to the userspace
and a way to fix their usage in each board in the device tree. If a board has a
relay line is a non-sense allow users in the userland to use it as an input line.

> I must admit that it has some elegance to it. Especially when it comes
> to scripting.

:)

> The problem I see is that lines are left in whatever state they were in
> if a script crashes, so there is no "return to the initial value" that was
> there when the GPIOs were picked from the device tree. This makes
> this a bit fragile.

I see but this interface is not designed for such complex usage nor to compete
with the current character interface! It is designed to allow boards
manufactures to "describe" some I/O lines that are not used by any driver in the
device tree, and that users may desire to manage in a very simple manner. Let's
thing about relay lines, or just a locked/unlocked input line which can be
easily polled.

> Also users regularly need to listen to events. This interface can and
> should never support that, for this one must use the character device,
> which will of course not work in parallel with using this sysfs ABI.
> And the day someone wants that we simply have to say no. There
> is no way to hold states for event handling in a stateless ABI.
> 
> Well of course they can poll for a line to change, but that is not
> proper event handling that reacts to an interrupt.

Again, the basic idea is not to compete with the current character interface nor
to manage interrupts lines, but just to have a really simple way to describe
those I/O lines which at the moment has no name nor references within the device
tree.

> So while this is much more elegant the old sysfs ABI, and certainly
> better for scripting, it still suffers from some conflicts with
> the character device, and there is a risk to make users dissatisfied
> when they want to e.g. script event handlers.
> 
> What are your thoughts on this?

Regarding the event handlers we can add irq supports... however I prefer to keep
this interface really simple just to not be confused with the character interface.

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