gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]

[Peter Naulls]

On 10/19/22 05:51, Lukas Zeller wrote:
> Hi,
> 

Lukas, thanks for this. I've read through everything and I agree with your
concerns. I'll note also that Linus W's commentary is from 2018.

>> On 19 Oct 2022, at 08:55, Petr Štetiar <ynezz at true.cz> wrote:
>>
>> IMO there should be `ugpiod` daemon available over ubus, probably written in
>> ucode using libgpiod bindings. It should provide ubus events for GPIO inputs
>> and should be able to control GPIO outputs using ubus calls.
> 
> What would that mean for performance, compared to more direct call chains
> as when using legacy /sys/class/gpio and current libgpiod? I suspect it would
> be much slower via an extra daemon.

Regarding performance, this is a practical concern. In one case using a GPIO-
driven 3-color LED, using explicit user-space tools (albeit a clunky vendor
program), to blink, there was a enough of a delay between the blinks to give
a disconcerting display when trying to blink white. I'm sure there's a better
way to do this, but changing the code to direct file access to the GPIOs
produced a more satisfactory result.

And I still haven't seen a rationale for the "non-fixed" base - I understand
there's probably a desire for abstraction somewhere, but figuring out
offsets becomes a hassle. I get that some boards have some wacky
GPIO assignments due to chip design, but this is surely a DTS concern.

I'm sure also it's trivial to extend the legacy GPIO export function to
export named GPIOs too (if it doesn't already, I haven't looked).

So for the moment, there doesn't seem to be general-purpose solution
in OpenWrt, especially for script use. I'll gladly migrate to that if
there is one in future, but I think for now I need to stick to my
patch and named GPIO exports in the DTS.