linuxgpio/libgpiod: using GPIOs on different chips

[mcuee]

Discussed in #2015

^{Originally posted by guillaume-jcb June 12, 2025}
Hello,

I'm trying to use a Coral board to program an Atmega 128a chip using the linuxgpio programmer. The Coral board exposes a few GPIO lines from different chips, as shown here: https://coral.ai/docs/dev-board/gpio/#header-pinout.

Since four GPIO lines are needed, I must use pins wired on different chips but it seems that − when arvdude is built with libgpiod support − it is assumed that all lines belong to a same chip, as can be inferred from the default_linuxgpio variable.

If libgpiod support is disabled, avrdude falls back to gool old sysfs GPIO interface which seems to work fine with this setup.

Am I overlooking something? Is it a known limitation of using libgpiod?

Thanks in advance for any insight! 🙏

[mcuee]

Comment from @mhei
*#2015 (reply in thread)

Good catch, and correct analysis. This is a limitation of the current libgpiod implementatation - not the library itself, but the avrdude programmers part. The reason is that the implementation tried to be backwards compatible to the sysfs configuration part. The sysfs configuration uses good old integer numbers for each gpio and each chip starts at a defined, mostly static offset.

For this request here, we would need to modify/extend the configuration file format. For example we could add a prefix, e.g. reset = 0.22 where 0 is then the number of the chip and 22 is the gpio line within this chip. When the prefix is missing, we could discuss, whether it should be assumed that chip is 0, or yet another default/fallback should be used.

Another option would be to allow strings as configuration value. The Linux kernel allows to define a "name" of each GPIO line which could be assigned in the Device Tree. Usually these names are then unique for a board, so it would be possible to refer to it and find the correct chip and gpio number with this name.
I think this name-based approach would be better in long-term. Just being curious about your coral board, does it define such names? You could check with "gpioinfo" output, or if you could share a device tree url here...

Just these thought for the moment, but to summarize: yes, this enhancement request makes a lot of sense.

[mcuee]

Comments from

• linuxgpio/libgpiod: using GPIOs on different chips #2015 (reply in thread)

Thanks for the detailed answer @mhei.

It seems that the GPIO lines are unnamed, as shown by the output of gpioinfo
gpioinfo.txt

For now I'll disable libgpiod support and see where it goes; or maybe use another board to program the device.