12/12/2018 13:46, Petr Štetiar:
Mathias Kresin <[email protected]> [2018-12-12 13:22:08]:
--- a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
@@ -9,15 +9,22 @@
compatible = "ubnt,xw", "qca,ar9342";
model = "Ubiquiti Networks XW board";
+ aliases {
+ led-boot = &boot;
+ led-failsafe = &failsafe;
+ led-running = &boot;
+ led-upgrade = &upgrade;
+ };
+
gpio-leds {
compatible = "gpio-leds";
- link1 {
+ upgrade: link1 {
label = "ubnt:red:link1";
gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
};
- link2 {
+ failsafe: link2 {
label = "ubnt:orange:link2";
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
@@ -27,7 +34,7 @@
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
};
- link4 {
+ boot: link4 {
label = "ubnt:green:link4";
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
};
Aren't these LEDs some kind of singal strength indicator? If so, they
shouldn't be used to indicate a running system. I'm fine to temporary hijack
the LEDs to indicate boot, failsafe and upgrade. But better use the same LED
for all of these (link1)?
I've simply thought, that while having so many LEDs available, it would be
better for UX (User Experience). Orange to signal failsafe mode, red to signal
ongoing upgrade. Using just one green LED to signal all the states might be
confusing and since we're using those LEDs only in cases when it's requested
by the user (failsafe/upgrade), I don't see it as a big deal to hijack them
for better UX as the RSSI won't be probably working at that time anyway
(not tested this scenario).
We had the discussion dozen times. The LEDs have a defined function on
these boards. Stick to this function.
Using different link LEDs might be obvious to you, every one else need
to have a look at the dts, to see which state is indicated by which
misused led.
Mathias
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
