On 09/01/2024 22:08, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Tue, Jan 9, 2024 at 8:10 PM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> 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@xxxxxxxxxx> >>>>> >>>>> 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? Mapping between colors and logical meanings is subjective. I don't think it is the same case as LED with a radio-signal or power-plug label. Anyway I also agree that this distinction is a bit blurred. Best regards, Krzysztof
