On Thu, Mar 12, 2026 at 08:41:03AM +0000, Jon Hunter wrote: > 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. You may use valid mask (which is also available via GPIO device properties) or as said below. In any case this thread just convinces me even more that driver has a design flaw. > > 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. None of Intel platforms has this issue, for the rest I have no clue. -- With Best Regards, Andy Shevchenko
