aboutsummaryrefslogtreecommitdiffstats
path: root/package/system
diff options
context:
space:
mode:
authorPiotr Dymacz <pepe2k@gmail.com>2020-01-31 15:22:54 +0100
committerPiotr Dymacz <pepe2k@gmail.com>2020-02-24 23:27:50 +0100
commita422b171ac17edde296b48e2b3e9c9845d773609 (patch)
tree5f783975960ec819789b2ebc2b2834a26f08c420 /package/system
parent2d113f89d230c2d337ce03217b3b9c1ca22975ea (diff)
downloadupstream-a422b171ac17edde296b48e2b3e9c9845d773609.tar.gz
upstream-a422b171ac17edde296b48e2b3e9c9845d773609.tar.bz2
upstream-a422b171ac17edde296b48e2b3e9c9845d773609.zip
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. Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de> Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Diffstat (limited to 'package/system')
0 files changed, 0 insertions, 0 deletions