GPIO numbering and ucidef_add_gpio_switch in kernel 6.6

[Robert Marko]

On Mon, 18 Mar 2024 at 06:31, Mathew McBride <matt at traverse.com.au> wrote:
>
> Hi all,
>
> A change in kernel 6.2 ("gpio: Get rid of ARCH_NR_GPIOS (v2)") [1] resulted in the GPIO chip base numbers changing on some architectures (x86, arm and arm64 were directly modified in that series).
>
> This may cause issues with /etc/board.d/03_gpio_switches scripts as the GPIO numbers will change when moving to the 6.6 kernel.

Hi Matthew,
This has been an issue for a while as GPIO numbers are not stable and
have never been guaranteed so.

>
> For example, on our (Traverse Ten64) board, the I2C GPIO expander (PCA953x) used to be numbered from 368, now it is numbered from 640:
>
> # Old
> cat /sys/kernel/debug/gpio:
> gpiochip4: GPIOs 368-383, parent: i2c/0-0076, 0-0076, can sleep:
> gpiochip3: GPIOs 384-415, parent: platform/2330000.gpio, 2330000.gpio:
> gpiochip2: GPIOs 416-447, parent: platform/2320000.gpio, 2320000.gpio:
> gpiochip1: GPIOs 448-479, parent: platform/2310000.gpio, 2310000.gpio:
> gpiochip0: GPIOs 480-511, parent: platform/2300000.gpio, 2300000.gpio:
>
> # New
> gpiochip0: GPIOs 512-543, parent: platform/2300000.gpio, 2300000.gpio:
> gpiochip1: GPIOs 544-575, parent: platform/2310000.gpio, 2310000.gpio:
> gpiochip2: GPIOs 576-607, parent: platform/2320000.gpio, 2320000.gpio:
> gpiochip3: GPIOs 608-639, parent: platform/2330000.gpio, 2330000.gpio:
> gpiochip4: GPIOs 640-655, parent: i2c/0-0076, 0-0076, can sleep:
>
> I have tried to address this in my armsr/6.6 pull request, but I don't think the solution is very elegant:
> https://github.com/openwrt/openwrt/pull/14896/commits/b74da3cd82d69e99dda357e61cae9b32072bca80
>
> (I still need to figure out uci migration of these settings between 6.1 and 6.6 systems)
>
> sysfs GPIOs have also been deprecated for a while now, but from the mailing list and GitHub archives, my understanding is that everyone was waiting for libgpiod v2 to come out before migrating. (libgpiod v2 was released in August 2023).
>
> I think kernel 6.6 may force this issue to be addressed. Should we try to migrate to a new system (e.g libgpiod) or work out a more agnostic way to discover GPIOs (sysfs, DTB etc.)?

Some kind of libgpiod integration seems like the only option to me currently.

Regards,
Robert
>
> Best Regards,
> Matt
>
> [1] https://lore.kernel.org/lkml/cover.1662116601.git.christophe.leroy@csgroup.eu/T/
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel