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

[Krzysztof Kozlowski]

On 09/01/2024 22:08, Geert Uytterhoeven wrote:
> 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?

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