[OpenWrt-Devel] RFC: conflicting LED usage (e.g. boot/wifi)

[p.wassi at gmx.at]

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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel