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

[Piotr Dymacz]

Hi Adrian,

On 05.11.2019 22:19, mail at adrianschmutzler.de wrote:
> Hi,
> 
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
>> On Behalf Of Adrian Schmutzler
>> Sent: Dienstag, 5. November 2019 16:12
>> To: openwrt-devel at lists.openwrt.org
>> Cc: Birger Koblitz <mail at birger-koblitz.de>
>> Subject: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-
>> export
>> 
>> From: Birger Koblitz <mail at birger-koblitz.de>
>> 
>> The gpio-export functionality is a hack for missing kernel functionality, which
>> was rejected in upstream kernel long time ago, for details see this email
>> http://lists.infradead.org/pipermail/openwrt-devel/2019-
>> February/015772.html,
>> discussion in PR#1366 or
>> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
>> 
>> This patch converts all DTS files with settings that normally do not need user
>> interaction, e.g. power for external USB ports, to gpio_hog. The only
>> remaining gpio-export will be in qca9558_openmesh_om5p-ac-v2.dts
>> 
> 
> 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.

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

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.

-- 
Cheers,
Piotr

> 
> 	/* power amplifier high power, 4.2V at RFFM4203/4503 instead of 3.3 */
> 	ath79_gpio_function_enable(QCA955X_GPIO_FUNC_JTAG_DISABLE);
> 	ath79_gpio_output_select(OM5PACV2_GPIO_PA_DCDC, QCA955X_GPIO_OUT_GPIO);
> 	ath79_gpio_output_select(OM5PACV2_GPIO_PA_HIGH, QCA955X_GPIO_OUT_GPIO);
> 	gpio_request_one(OM5PACV2_GPIO_PA_DCDC, GPIOF_OUT_INIT_HIGH,
> 			 "PA DC/DC");
> 	gpio_request_one(OM5PACV2_GPIO_PA_HIGH, GPIOF_OUT_INIT_HIGH, "PA HIGH");
> 
> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pacv2.c
> 
> Thus, I will also convert that device without an explicit resend of the patch unless there is protest about it.
> 
> 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