Hi Adrian,
On 06.11.2019 00:14, [email protected] wrote:
Hi,
TL;DR:
1. We should find an agreement that can be used coherently at least for new
device support submissions.
I believe the major issue here is that there is no 'in place'
replacement for 'gpio-export' (or I'm just not aware of it).
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.
It seems this one has two levels of amplification, depending on the
supply voltage (3.3V vs. up to 5V). And based on the GPIO names and
comments in code, this can be controlled with GPIOs.
Another question here is 'should we allow user to change such
settings?'. I'm not that strict and I believe user is owner of the
hardware and should be able to do with it whatever is possible but I
know there are developers with different opinions on the subject.
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.).
Are there any other reasons to get rid of 'gpio-export' _now_, other
than the fact upstream rejected this approach?
Wouldn't it make more sense to spend time now on implementing
future-proof solution and switch to it when it's ready?
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.
Even if there is no alternative?
We should really make such decision more transparent, public and give
users and downstream projects time to adopt for the change.
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).
'03_gpio_switches' doesn't handle inputs.
Of course, it has advantages, like the fact it makes the GPIO setup
uci-based but on the other hand... it does its job fairly late during
bootup. In some cases, you might want to, for example, enable power for
3/4G modem as early as possible, to give it time to register in network.
Anyway, under the hood, it's the same approach, export named GPIO using
_deprecated_ sysfs. Excluding uci and place in boot time where it
happens, the difference is where the GPIOs are defined, DTS vs.
user-space scripts.
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?).
I suppose you don't have much experience with USB based 3/4G modules :)
Faulty or not, workaround or just user's need, people are using them and
we shouldn't make it hard for them. I definitely wouldn't want OpenWrt
to become a platform where user is... just a user of 'rented' hardware,
like many vendors are trying to achieve.
In case of VBUS I'm pretty sure 'regulator' is a better approach than
'gpio-hog'. At least in that case there is a way to disable VBUS by
unloading host driver (see for example 'mt7621_xiaomi_mir3g.dts' under
ramips). But still, there are corner cases (based on a real device) -
this won't work if device has two USB ports (under the same HUB on
single bus), with separated GPIO-controlled VBUS supply.
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.
I believe it's time to think about future-proof solution first.
So please, share your views on this topic, so we might extract a path to go
ahead.
IMHO, 'gpio-hog' should replace 'gpio-export' where there is no other,
more suitable solution (dedicated driver, like 'regulator') but not
before we can offer users replacement for deprecated sysfs approach.
Thus, personally I would prefer to start discussion about our 'version'
of libgpiod instead. That's my view.
--
Cheers,
Piotr
Best
Adrian
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
