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

[Lukas Zeller]

Hi,

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

But I see a basic underlying question here: how to look at GPIOs in the general
context of OpenWrt?

- From a systems designers perspective, a GPIO is a I/O pin of the SoC or one
  of the peripheral chips in the system which has no specific function
  determined by the silicon, but gets one by the board/device design.
  This is the main perspective in Linux, and DT is the layer to "wire" the
  GPIOs for the specific task to run a certain board or device.

- From the perspective of people who build educational or experimental
  devices, where reconfiguring GPIOs is a essential part of the USER
  experience, changing DT bindings (be it just `gpio-line-names`) is not
  a viable solution. Especially not since the mechanism to do so without
  rebuilding firmware images - dynamically loading DT overlays - is not
  approved of as well [1]. For this perspective, deprecating old GPIO numbering
  and retiring spi-gpio-custom et. al. drivers with no real substitute
  is a serious step backwards, and a reason not to upgrade to newer versions.

I see that the first of the two perspectives is the correct one for the main
usage of OpenWrt, an OS for network boxes and boards, and obviously has
priority.

However, OpenWrt is also a very good base for other uses, maybe summarizable
as "user configurable hardware controllers" (as said, education, but also
controllers for exhibitions and art installations - one of my primary
applications).

After years using and trying to contribute to OpenWrt for this
use case I still don't really understand the sentinents of core OpenWrt
towards this sideline - is it rather seen as a distracting nuisance or
an opportunity? ;-)

Somehow I need to have a clearer view on this meta level to do more than
just patch the missing things for myself. I would like to not only
profit, but also contribute, but can do only so from and for the second
of the two perspectives above, because that's what I understand and work
with.

Any thoughts?

Best Regards
Lukas

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037164.html


> Bjørn Mork <bjorn at mork.no> [2022-10-19 08:24:44]:
> 
>> Sergio Paracuellos via openwrt-devel <openwrt-devel at lists.openwrt.org>
>> writes:
>> 
>>> This is the reason we have 'gpio-line-names' property so you can set
>>> up names for your pins and use it together with actual user space
>>> tools libgpiod and gpiod. Any other gpio user space library is
>>> considered deprecated in these days.
>> 
>> Interesting.  This property doesn't seem to be used much in OpenWrt if
>> my grep foo is good. It should probably be added at least to every
>> system where we want to access GPIOs from userspace?
> 
> Yes, that is my[1] understanding as well.
> 
> 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376
> 
> -- ynezz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20221019/c99fc525/attachment.sig>