On 04/02/20 13:32, Adrian Schmutzler wrote:
Hi,
-----Original Message-----
From: openwrt-devel [mailto:[email protected]] On
Behalf Of Piotr Dymacz
Sent: Freitag, 31. Januar 2020 15:23
To: [email protected]
Subject: [OpenWrt-Devel] [PATCH] base-files: diag: restore default trigger for
'boot' LED
For devices without a dedicated 'diag' LED, we use sometimes one of
other LEDs for indicating at least 'boot', 'failsafe' and 'upgrade'
stages. In some cases, at the same time these LEDs have defined default
triggers in DTS using 'linux,default-trigger' property. Current 'diag'
setup removes the trigger and turns off 'boot' LED after bootup.
One of the examples of such device is TP-Link TL-WR841N v14 (ramips)
which uses 'wlan' LED with defined 'linux,default-trigger' for 'diag':
aliases {
led-boot = &led_wlan;
led-failsafe = &led_wlan;
led-upgrade = &led_wlan;
};
[...]
led_wlan: wlan {
label = "tl-wr841n-v14:green:wlan";
gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy0tpt";
};
This patch extends 'diag.sh' and 'leds.sh' scripts to make sure default
trigger defined in DTS is restored for 'diag' LED which isn't used for
indicating 'running' stage.
I'm not really a fan of using LEDs for diag in that case at all, and I'd
actually prefer to have the aliases removed there (unless vendor also used
multiple purpose LEDs the same way).
I don't like this either, but I think functionality always wins over
esthetics.
Showing boot status and the moment to press the reset button to enter
failsafe is
more important than the "uglyness" of hijacking a LED.
Besides, in many cases (wifi led for example) the device won't be using
that led during boot anyway.
-Alberto
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
