diff options
author | Piotr Dymacz <pepe2k@gmail.com> | 2020-01-31 15:22:54 +0100 |
---|---|---|
committer | Piotr Dymacz <pepe2k@gmail.com> | 2020-02-24 23:27:50 +0100 |
commit | a422b171ac17edde296b48e2b3e9c9845d773609 (patch) | |
tree | 5f783975960ec819789b2ebc2b2834a26f08c420 /scripts/cleanfile | |
parent | 2d113f89d230c2d337ce03217b3b9c1ca22975ea (diff) | |
download | upstream-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 'scripts/cleanfile')
0 files changed, 0 insertions, 0 deletions