gpio-mt7621 offset fix for 5.10 kernel series

[Peter Naulls]

On 10/18/22 15:55, Martin Blumenstingl wrote:
> Hello Peter,
> 
> On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls <peter at chocky.org> wrote:
>>
>>
>> Looks like there was some code loss when the driver came from an earlier kernel
>> series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
>> number, I don't know):
> You should also explain the problem with this behavior (if there's any).
> 
> Upstream kernel doc [0] mentions:
>   * @base: identifies the first GPIO number handled by this chip;
>   * or, if negative during registration, requests dynamic ID allocation.
>   * DEPRECATION: providing anything non-negative and nailing the base
>   * offset of GPIO chips is deprecated. Please pass -1 as base to
>   * let gpiolib select the chip base in all possible cases. We want to
>   * get rid of the static GPIO number space in the long run.
> 
> I never used it but my understanding is that the recommended way for
> accessing GPIOs from userspace (in case that's what you need) should
> be done through libgpiod.

Thanks for pointing me at this. Of course, I don't keep tabs on all the
kernel development.

I will say the following though:

It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes
from some calculation.

All/most of the other ramips use the ramips GPIO driver instead, which
does specify the base, although that's in the the DTS; there's no
facility for that in the mt7621 setup at present.

I ended up using named GPIO mappings set up in the DTS, which appears to
be OK.  I was chasing some additional GPIO issues vs what I had working
on an earlier kernel series - it didn't immediately help, but it was
an obvious inconsistency.