Hey Daniel,
12.09.2018 04:24, Daniel F. Dickinson:
Hi,
I'm having trouble finding a concise summary of what is the policy for
using multiple leds for boot/failsafe, etc status (in this case updating
CAP324 to use both colours of the 'power' led, now that such logic in in
ath79 tree).
There is no strict policy, it depends more or less on the preference of
the contributor.
Nevertheless, there seem to be some common approaches in handling
multiple power leds (OR):
- match the behaviour of the stock firmware
- bi-color led: use the second/warning/red color to indicate a critical
situation like failsafe
- tri-color led: one color for booting, one color for failsafe and one
color for "system is up, runnning and everything fine"
Assuming the CAP324 bootloader passes a lit amber power led to the
kernel, it would be fine to use this one by default and switch to the
green one to indicate "system is up, runnning and everything fine".
I only remember to asked once to change the status led color. It either
was a board with only one multi color led or the majority of the leds
were green. The contributor used a red led to indicate "system is up,
runnning and everything fine". I didn't felt comfortable with the
decision, as red is warning color for me.
On the other hand, I have a vodafone branded CPE here, where the stock
firmware uses the red color mode for all leds to indicate the fine state
and the blue color mode for failures. I kept it this way.
As you can see, it is hard to define any hard rules about what should be
used.
Also are leds supposed to be named according to manufacturer or
according to model number (presuming that for ath79 we don't care about
using the same led names as for ar71xx)?
We are following what is requested upstream: <board>:<color>:<function>.
At the moment the only exception should be tp-link boards, as the leds
(and gpios used for them) are identical for a lot of boards.
Using the manufacture instead of the board name for these, allows us to
add the led block to a dtsi file and (re)use it for multiple dts files
including this dtsi.
It's something we've done already in ar71xx and it might change if
someone decides following the upstream standard is more valuable than
de-duplicating similar code.
Also pursuant to https://github.com/openwrt/openwrt/pull/1062 should
CAP324 be DHCP or a static IP on it's only wired interface? (It's an AP).
For now static, till a decision about PR#1062 is made.
Mathias
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
