gpiod-tools: gpioinfo: error creating line iterator

[RoEdAl]

gpiod-tools: gpioinfo: error creating line iterator

gpioinfo from gpiod-tools package reports error:

gpioinfo: error creating line iterator: Invalid argument

This is because kernel config CONFIG_GPIO_CDEV_V1 is not enabled on most targets.

Theoretically CONFIG_GPIO_CDEV and CONFIG_GPIO_CDEV_V1 configs are enabled in Makefile but apparently configuring kernel via KCONFIG does not work. Maybe KCONFIG is honored in kernel packages only and silently ignored in normal packages (or packages from feeds)?

[aguaviva]

I am having the same issue on

Hostname	OpenWrt
Model	        Mediatek MT7628AN evaluation board
Architecture	MediaTek MT7688 ver:1 eco:2
Target Platform	ramips/mt76x8
Firmware Version	OpenWrt 23.05.2 r23630-842932a63d / LuCI openwrt-23.05 branch git-23.306.39416-c86c256
Kernel Version	5.15.137

apparently now we have to use gpioctl-sysfs as the gpiod-tools got deprecated

[RoEdAl]

No, libgpiod isn't deprecated at all. It's quite opposite - sysfs GPIO access is deprecated for years. See here for more info.

The problem is that OpenWRT still uses v1 of libgpiod so proper kernel config (CONFIG_GPIO_CDEV_V1 along with CONFIG_GPIO_CDEV) must be enabled.

I think that libgpiod library/tools should be considered as core packages and moved to main OpenWRT repo.

[aguaviva]

you are right, and thanks for the great article!

[mhei]

Theoretically CONFIG_GPIO_CDEV and CONFIG_GPIO_CDEV_V1 configs are enabled in Makefile but apparently configuring kernel via KCONFIG does not work. Maybe KCONFIG is honored in kernel packages only and silently ignored in normal packages (or packages from feeds)?

I've just tried whether this (still) works on latest main/master branch and yes, works for me. But I'm also making a complete build. My procedure was to first build for Raspberry Pi without libgpiod selected in menuconfig, this results in a kernel config without CONFIG_GPIO_CDEV_V1 enabled. Then I additionally selected libgpiod, rebuilt and verified that CONFIG_GPIO_CDEV_V1 is now set in kernel .config. Maybe do you use SDK or IB...?

PS: At the moment, the upgrade to libgpiod v2 API is kind of stalled due to missing capacity: we have openocd as libgpiod consumer in the repo but this still depends on libgpiod v1. I've not yet noticed any efforts to upgrade the openocd part to newer libgpiod API. If you know about existing patches, please tell me. Personally, I'm no user of openocd but I meanwhile managed to setup a minimal test setup using a Raspberry Pi with a JTAG device. My plan is to make simple regressions tests on that base so that I can craft a patch for openocd. Any help on this topic would be really appreciated.

[RoEdAl]

Maybe it is working for you but it doesn't work in official images (23.05) and snapshots. I guess this may be a bug in image building pipeline.

[ryjelsum]

I can confirm that this issue is present in the official image that is released for the Linksys EA6350 v3, version 23.05.02. Pretty much freshly updated, installed the gpiod-tools package, and got the exact same behavior as OP. I'm building my own image for this down the line anyhow, so I'll see if I can reproduce the behavior mhei is describing, which would line up with both of your observations. Maybe then somebody could suggest a concrete course of action?

[mhei]

I think the best option is really to get rid ASAP of the older libgpiod and switch to newer version so that we do not need to enable the CONFIG_GPIO_CDEV_V1 stuff. The in-tree packages affected (dependencies) are openocd and avrdude, and I'm already working on upstream patches for libgpiod v2 support for both projects (see e.g. https://review.openocd.org/c/openocd/+/8184 and https://github.com/avrdudes/avrdude/pull/1725) My idea was to backport the patches once ready to our OpenWrt build (in case a new upstream release is not in line of sight).