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

Jon Hunter
2026-03-12T08:41:15Z

On 12/03/2026 07:49, Chen-Yu Tsai wrote:

...

>>> 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.

Right. I was thinking that isn't this why we have the xlate callbacks in
the first place to handle such things and not make these assumptions?

I am curious if other platforms could have the same issue? I did not see
this immediately with v6.19 because it is only one specific platform we
have that showed this. So very much a corner case that will only be seen
if a platform uses shared GPIOs and the shared GPIO happens to be high
enough to overflow the descriptor array. Even if we don't crash, at
least for Tegra, we could be using the wrong descriptor too for shared
GPIOs.

Jon

--
nvpublic