[PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

[Geert Uytterhoeven]

Hi Krzysztof,

On Tue, Jan 9, 2024 at 8:10 PM Krzysztof Kozlowski
<krzysztof.kozlowski at linaro.org> wrote:
> On 09/01/2024 17:38, Rafał Miłecki wrote:
> > On 9.01.2024 10:02, Krzysztof Kozlowski wrote:
> >> On 09/01/2024 09:23, Rafał Miłecki wrote:
> >>> From: Rafał Miłecki <rafal at milecki.pl>
> >>>
> >>> OpenWrt project provides downstream support for thousands of embedded
> >>> home network devices. Its custom requirement for DT is to provide info
> >>> about LEDs roles. Currently it does it by using custom non-documented
> >>> aliases. While formally valid (aliases.yaml doesn't limit names or
> >>> purposes of aliases) it's quite a loose solution.
> >>>
> >>> Document 4 precise "chosen" biding properties with clearly documented
> >>> OpenWrt usage. This will allow upstreaming tons of DTS files that noone
> >>
> >> typo: none
> >
> > typo: no one ;)
> >
> >>> cared about so far as those would need to be patched downstream anyway.
> >>
> >>  From all this description I understand why you want to add it, but I
> >> don't understand what are you exactly adding and how it is being used by
> >> the users/OS.
> >
> > In OpenWrt we have user space script that reads LED full path:
> > cat /proc/device-tree/aliases/led-<foo>
> >
> > And then sets LED to state matching current boot stage:
> > echo 1 > /sys/class/leds/<bar>/brightness
>
> OK, it's nowhere close to a hardware property. You now instruct OS what
> to do. It's software or software policy.

> >> Anyway, we have existing properties for this - LED functions. Just
> >> choose LED with given function (from sysfs) and you are done. If
> >> function is missing in the header: feel free to go, least for me.
> >
> > In "Describing LEDs roles in device tree?" e-mail I wrote:
> >
> > "
> > Please note that "function" on its own is not sufficient as multiple
> > LEDs my share the same function name but its meaning may vary depending
> > on color.
> > "
> >
> > Let me elaborate here.
> >
> > Values of "function" property match LEDs descriptions (usually it's a
> > physical label). That is OK and makes sense but doesn't allow OpenWrt to
> > automatically pick proper LED to use during given boot stage.
> >
> > Some devices may have multiple color of a the same LED function. OpenWrt
> > developer needs to choose which color to use for failsafe more and which
> > boot fully booted state (and others too).
> >
> > Devices also differ in available LEDs by their functions. Some may have
> > LED_FUNCTION_POWER that OpenWrt needs to use. Some may have
> > LED_FUNCTION_STATUS. Or both. There are some more (less common)
> > functions like LED_FUNCTION_ACTIVITY.
> >
> > We failed at OpenWrt to develop a single generic script to rule all
> > devices and all their LEDs combinations. We ended up with developers
> > *choosing* what LED to use for a given system state.
>
> So this all is because you want to write easier OS. That's abuse of
> Devicetree. You can define which LEDs have different meaning, e.g.
> physical label or icon attached to them. That's a hardware property.
>
> You can also define how pieces of hardware are wired together and create
> entire system, e.g. connect one LED to disk activity.
>
> However what you are proposing here is to dynamically configure one,
> given OS. I don't think it is suitable.
>
> The problem of OS to nicely figure out which LED to blink when, is not a
> problem of Devicetree. It is a problem of OS and its configuration.

I'd say it's a grey area...

What if the colors are printed on the case, next to the LED?
Like these multi-color LEDs indicating port speed on network switches?
Then it suddenly becomes hardware description, just like
"aliases/serial2 = &...;" referring to serial port 2.

Next, what if the colors are not printed on the case, but documented
in the product's manual?
What if there is no paper product manual, but just the OpenWRT online
documentation?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds