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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
