Thread (71 messages) 71 messages, 19 authors, 2026-03-13

Re: [PATCH v4 03/10] gpiolib: implement low-level, shared GPIO support

From: Bartosz Golaszewski <brgl@kernel.org>
Date: 2026-03-13 14:18:48
Also in: linux-arm-msm, linux-gpio, linux-hardening, linux-sound, linux-tegra, lkml

On Thu, Mar 12, 2026 at 8:49 AM Chen-Yu Tsai [off-list ref] wrote:
On Thu, Mar 12, 2026 at 3:29 PM Jon Hunter [off-list ref] wrote:
quoted

On 11/03/2026 20:14, Andy Shevchenko wrote:
quoted
On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter [off-list ref] wrote:
quoted
On 12/11/2025 13:55, Bartosz Golaszewski wrote:
...
quoted
On Tegra234, the main gpio controller has a total of 164 GPIOs (see
the tegra234_main_ports in drivers/gpio/gpio-tegra186.c). The GPIOs
are assigned a index by the kernel from 0-163, but these GPIOs are
not contiguous with respect to the device-tree specifier.
If I may ask...

Why? Is it sparse because there are pads that can't be used as GPIOs?
It is purely how the different port for the GPIO controller are
configured in h/w ...

static const struct tegra_gpio_port tegra234_main_ports[] = {
         TEGRA234_MAIN_GPIO_PORT( A, 0, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( B, 0, 3, 1),
         TEGRA234_MAIN_GPIO_PORT( C, 5, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( D, 5, 2, 4),
         TEGRA234_MAIN_GPIO_PORT( E, 5, 3, 8),
         TEGRA234_MAIN_GPIO_PORT( F, 5, 4, 6),
         TEGRA234_MAIN_GPIO_PORT( G, 4, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( H, 4, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( I, 4, 2, 7),
         TEGRA234_MAIN_GPIO_PORT( J, 5, 0, 6),
         TEGRA234_MAIN_GPIO_PORT( K, 3, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( L, 3, 1, 4),
         TEGRA234_MAIN_GPIO_PORT( M, 2, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( N, 2, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( P, 2, 2, 8),
         TEGRA234_MAIN_GPIO_PORT( Q, 2, 3, 8),
         TEGRA234_MAIN_GPIO_PORT( R, 2, 4, 6),
         TEGRA234_MAIN_GPIO_PORT( X, 1, 0, 8),
         TEGRA234_MAIN_GPIO_PORT( Y, 1, 1, 8),
         TEGRA234_MAIN_GPIO_PORT( Z, 1, 2, 8),
         TEGRA234_MAIN_GPIO_PORT(AC, 0, 1, 8),
         TEGRA234_MAIN_GPIO_PORT(AD, 0, 2, 4),
         TEGRA234_MAIN_GPIO_PORT(AE, 3, 3, 2),
         TEGRA234_MAIN_GPIO_PORT(AF, 3, 4, 4),
         TEGRA234_MAIN_GPIO_PORT(AG, 3, 2, 8),
};

Each port can have upto 8 pins, but some don't. Note the last number in
the column indicates the number of pins for a port.
quoted
quoted
For example, in device-tree, if I have a shared-gpio with the
following specifier ...

   gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;

The macro TEGRA234_MAIN_GPIO(AF, 1) evaluates to (23 * 8) + 1 = 185.
To me it sounds like a bad design of the driver for this SoC/platform.
I am not sure why you think that. Assuming a 1:1 mapping of the kernel's
GPIO index to the GPIO controller + h/w port + 1 GPIO number seems fragile.
If the hardware has uneven number of actual pins for each bank, either
you end up using the deprecated static GPIO number allocation and
have holes in the GPIO range (sunxi currently does this), or you use
dynamic allocation, which gives you no holes in the GPIO range, but
not directly calculable mapping between DT and GPIO numbers.

The driver handles the mapping by providing an .xlate callback. A
consumer shouldn't assume anything. The shared GPIO library probably
shouldn't be try parsing the property itself and use the result to
grab the GPIO descriptor, but just rely on the gpiochip's .xlate
callback in some way.
Yes, it's a bug. I will fix it. Thanks for the report Jon.

Bart
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help