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
