Hi Sergio, thanks for the reply! On 21 Jan 2023, at 14:00, Sergio Paracuellos <[email protected]> wrote:
> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
