On Mon, 18 Mar 2024 at 06:31, Mathew McBride <m...@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.le...@csgroup.eu/T/ > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel