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

[Piotr Dymacz]

Hi Adrian,

Sorry for a late reply.

On 06.11.2019 16:47, Adrian Schmutzler wrote:
> Hi,
> 
>> Wouldn't it make more sense to spend time now on implementing
>> future-proof solution and switch to it when it's ready?
> 
> Obviously, yes. But for the meantime, I'd like to have a less-arbitrary status quo.

For me, in that case, I would leave decision to the author of support 
_and_ reviewer/committer.

>> 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).
>> 
> [...]
>> 
>> Are there any other reasons to get rid of 'gpio-export' _now_, other
>> than the fact upstream rejected this approach?
>> 
>   [...]
>> 
>> '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.
>> 
> 
> So, both 03_gpio_switches and gpio-hogs provide less functionality than gpio-exports with no striking benefit. From that point of view we should actually allow gpio-exports in device support submissions again, and actually discourage gpio_hogs for the status quo ... (and it would be better to convert hogs to exports and not the other way around ...)

Someone could say that 'gpio-hog' is the accepted solution in upstream 
and the 'gpio-export' is the rejected one so we need to get rid of it ASAP.

Personally, I don't see now any good reason to convert everything back 
to 'gpio-export'. I would be just more pragmatic when reviewing and 
accepting boards support - if the author thinks that it would be better 
(look at it from usability point of view) to have user-space control on 
a specific GPIO line, I wouldn't ask him to use 'gpio-hog'. For me, also 
the uci approach is fine if there is no need to setup GPIO before the 
whole boot process finishes.

Still, in some cases maybe 'fixed-regulator' would fit even better than 
discussed solution. IIRC, at least in case of the USB, there is still a 
way to have control on the VBUS if 'fixed-regulator' is used (unload the 
driver, power goes off, load it back, power goes on).

I just don't think it makes sense to look for a consensus now on 
something which for sure has to go away/change in, I hope close future.

-- 
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