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

Chen-Yu Tsai
2026-03-12T07:49:57Z

On Thu, Mar 12, 2026 at 3:29 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 11/03/2026 20:14, Andy Shevchenko wrote:
> > On Wed, Mar 11, 2026 at 8:38 PM Jon Hunter <jonathanh@nvidia.com> wrote:
> >> On 12/11/2025 13:55, Bartosz Golaszewski wrote:
> >
> > ...
> >
> >> 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.
>
> >> 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.

ChenYu