mt7621 GPIO mapping mystery

[Lukas Zeller]

Hi Sergio, thanks for the reply!

On 21 Jan 2023, at 14:00, Sergio Paracuellos <sergio.paracuellos at gmail.com> wrote:

> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller <luz at plan44.ch> wrote:
>> [...]So while I understand that using only the DT mechanisms for configuring GPIO modes, named gpios and libgpiod instead of /sys/class/gpio etc. is the way to go, I must also state that without loadable DT overlays, this essentially makes openwrt unsuitable for experimental/educational devices.
> 
> Configure the GPIO modes is not something that is expected to be done
> by a user since all of that belongs to the pinctrl driver space and
> AFAIK linux kernel people are not thinking in doing pinctrl driver
> user-space tools.

Apparently, yes.

I also fully understand this from a system designer's point of view.

What pin is connected to what external hardware, is something that is, in a given system, on a given PCB, pretty immutable and thus DT is the correct and only place to also define it in a way that is immutable between flashing firmwares.

> The libgpiod is useful to detect and set to on and
> off different pins (among other pure GPIO operations) but from the
> already function GPIO set up in them.

This draws a pretty arbitrary boundary for what a educational/experimental use consists of. Toggling predefined GPIOs on and off, yes, using the same pin for PWM (say, GPIO18 on MT76x8), no? rotary-encoder? W1? GPIO-based SPI, I2C?

> I am not doing the rules,

:-)

> I am just saying the things that are now in the kernel and user space as I
> think they are. As I have already said, I am not an expert in this
> topic at all but maybe if we want to do such complex things like
> configuring the mode of a pin from user space some kind of user space
> drivers need to be provided in some way... So, if openWRT is using
> linux kernel, at the end they have to also live with kernel people's
> decisions in some way...

In some way.

But OpenWrt does patch the kernel to adjust things that Linux mainline does not provide.

So it *is* an OpenWrt question whether to support HW tinkering and to what degree.

Having that loadable DT overlay patch (which works on 5.10, I'm using it) as a menuconfig option disabled by default would have two benefits:

- going with the linux kernel way, to have these HW config things in the DT, and only there.

- one single, completely HW independent switch, off by default, to allow HW experiments or not (compiling in the dynamically loadable DT overlays code).

Builds for targets that *want* to be open for educational/experimental HW tinkering, with the set of risks that comes with that, can set this switch. All normal router targets will not set set it, and thus are not affected.

I think this would be better and easier to maintain, than reverting back to driver-level hacks like we had in 19.x with *_gpio_custom and friends.

So basically, I'm suggesting to revisit the decision to reject the patch from Daniel Golle [1].

Regards,
Lukas

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20230121/1af5628e/attachment-0001.sig>