Dear list, on a small number of devices on ath79 we face the issue, that LEDs, which are used as boot indicators also have a linux,default-trigger set (for e.g. the wifi or usbport)
This is not limited to ath79, but in principle affects all device-tree targets. Example on ath79: the GL.iNet GL-AR150: On ar71xx, the LED blinks during bootup of the system and then switches function to be a wifi indicator (through board.d/01_leds) However, on ath79, this is currently not possible. For device-tree there are four different status indicators: (/etc/diag.sh) - boot (blinking during preinit / preinit_regular) - failsafe (blinking during failsafe) - running (off in failsafe or upgrade, on when system booted) - upgrade (blinking when in upgrade state) On many devices (not all), all four options reference the same LED in the devicetree. While it does not make sense / is not possible to have one single indicator for RUNNING and WIFI, we could address this by not setting the 'running' LED. I.e. the LED could first indicate boot, and then (once booted) indicate Wifi. How do we want to deal with LEDs having multiple functions? As there are devices that do not have an explicit system/boot/whatever-LED, simply dropping the boot-indicator function is not an option for me. Right now, using both is only possible, if the second trigger is set through 01_leds. (I.e. the default-trigger from device-tree is ignored if the LED was used during bootup) --- My proposed solution to this issue is as follows: If a device does not have a distinct system-LED (i.e. all LEDs are used for another purpose), the device tree MUST NOT set the 'led-running' property. Dual-use LEDs for netdev devices do not need further treatment, their triggers are set through board.d/01_leds Other dual-use LEDs, which have their triggers in device-tree (in the linux,default-trigger property), do need some changes: The script etc/diag.sh controls the system LEDs during bootup and also knows when bootup is finished ("done"). On this event, the diag.sh could withdraw its use of the LEDs and pass the command over to the secondary function as set in the DTS. I.e. it has to set the linux,default-trigger in the LED's sysfs path. A proposal for a patch - which does not work in all cases yet (usbport, trigger-sources) as well as further discussion with @mkresin is given in https://github.com/openwrt/openwrt/pull/1698 Thanks for your opinions, best regards, P. Wassi _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel