Hi, TL;DR: 1. We should find an agreement that can be used coherently at least for new device support submissions. 2. Everyone (and particular committers) feel invited to add your view.
> > I've just had a look at the openmesh_om5p-ac-v2, and it seems as if the > gpio-exports there are just voltage changes for a power amplifier. To me this > looks like those can be dealt with by a gpio-hog, too: > > What if someone would like to lower TX power on this board? With gpio-hog > that wouldn't be possible anymore. I would personally consider that change > as a user experience limitation or even a regression. Well, normally I'd say to lower the TX power you would use the user-space txpower setting and not change voltages of an amplifier. Nevertheless, I'm not religious about the gpio-hogs, I just want to get the gpio-exports off the table. If the majority thinks everything should rely on 03_gpio_switches, I will happily implement it (though this might be a problem for people updating into it.). > > I had this discussion many, many... many times before with Mathias (and I > believe we still agree to disagree on this topic). Until there is a dedicated > driver for such features controlled by GPIOs (lets say, SIM switching, driving > relays, enabling higher power output in ext PA, etc.), switching from gpio- > export to gpio-hog only limits user control on the hardware they own and in > fact doesn't get us closer to something which could make the gpio-export > finally go away (libgpiod). Yes, I read the old discussion before I asked for closing it. Despite my desire to get rid of the "old" gpio-exports, note that we currently do not accept gpio-exports for new device support (for several months already). So there is no "keep gpio-exports until we have something better", unless we start accepting it for submissions again. > > I'm always on the end user side here. If the hardware is capable of switching > something with GPIO, user should have a way to make use of that. Even if > current solution was rejected in upstream. So, that would mean that we use 03_gpio_switches from now on, at least for new submissions. This would be a change of what mostly has been done so far (reviewers suggesting to use gpio_hog). The big majority of what we deal with is USB power. I've read Enrico's arguments, but I'm not really convinced that resetting an USB device by toggling its power really is a feature, and not just a workaround for a faulty USB device. That's why I personally can well live with having USB power for external ports set by hogs, and anything else converted to user space switches. But I also admit that you (Piotr) are right that this is a reduction of user power over the device (I suspect it would be the same with the fixed regulator?). At the end, I'm fine with gpio_hogs, 03_gpio_switches or a mixed solution, but I think it's time to have a decision on that topic, instead of determining the correct solution based on who is reviewing a patch. So please, share your views on this topic, so we might extract a path to go ahead. Best Adrian
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
