Hi, > On 19 Oct 2022, at 08:55, Petr Štetiar <yn...@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 <bj...@mork.no> [2022-10-19 08:24:44]: > >> Sergio Paracuellos via openwrt-devel <openwrt-devel@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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel