On 10/18/22 15:55, Martin Blumenstingl wrote:
Hello Peter,
On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls <pe...@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.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
