[OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[Piotr Dymacz]

Hi Adrian,

On 06.11.2019 00:14, mail at adrianschmutzler.de 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
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel