Gpiochip enumeration/base changed between 23.05 and 24.10?

Preface: This is not a problem, just a request for a bit of clarification.

I have here a few x86 NAS boxes currently happily running 23.05. I wrote custom scripts to make proper use of their built-in LEDs and buttons, and to that end I brute-force figured out the GPIOs the LEDs and the buttons are attached to. So far so good.

However, with 24.10, my scripts stopped working. After a brief period of befuddlement, I realized that between the two OpenWrt versions the order of gpiochips and their base offsets have been changed:

With 23.05 they look like this, in descending order and with an inexplicable base offset of 740:

gpiochip3: GPIOs 740-825, parent: platform/INT33FF:03, INT33FF:03:
gpiochip2: GPIOs 826-852, parent: platform/INT33FF:02, INT33FF:02:
gpiochip1: GPIOs 853-925, parent: platform/INT33FF:01, INT33FF:01:
gpiochip0: GPIOs 926-1023, parent: platform/INT33FF:00, INT33FF:00:

With 24.10 they now are in ascending order, with a "round numbered" base offset:

gpiochip0: GPIOs 512-609, parent: platform/INT33FF:00, INT33FF:00:
gpiochip1: GPIOs 610-682, parent: platform/INT33FF:01, INT33FF:01:
gpiochip2: GPIOs 683-709, parent: platform/INT33FF:02, INT33FF:02:
gpiochip3: GPIOs 710-795, parent: platform/INT33FF:03, INT33FF:03:

Now, I can work around this by grepping and awking my way to the correct chip and its base and offsetting the GPIO numbers from there. That is not the issue.

But what I would like to know is the reason for this change. Is this a consequence of the new kernel or a change in the kernel driver? Should gpiochips generally be considered "floating"? Can I at least rely on the gpiochip labels staying constant?

According to this commit message it's due to the kernel upgrade and it seems to affect other targets as well. It's even worse regarding the GPIO switches: If you keep the configuration files, the old GPIO number remains in /etc/config/system and is never updated. I ran into this just yesterday.

1 Like

You're right. After some googledigging I found the following on our very own mailing lists:

"GPIO numbering and ucidef_add_gpio_switch in kernel 6.6"
https://lists.infradead.org/pipermail/openwrt-devel/2024-March/042448.html

The linked Lore thread is especially insightful. It seems to be a peripheral effect of mainline phasing out sysfs GPIOs. Which makes me think whether I should stick with my workaround or bite the bullet and refactor my scripts for gpiod(-tools).