Re: [PATCH v3] ARM: dts: renesas: r9a06g032-rzn1d400-db: describe Debug LEDs

[Jacek Anaszewski <jacek.anaszewski@gmail.com>]

Hi Geert,

On 5/12/25 09:13, Geert Uytterhoeven wrote:
> Hi Jacek,
> 
> Thanks for your answer!

You're welcome.

> On Sat, 10 May 2025 at 14:43, Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>> On 5/8/25 15:49, Lee Jones wrote:
>>> On Thu, 08 May 2025, Wolfram Sang wrote:
>>>> On Thu, Apr 17, 2025 at 01:39:14PM +0200, Geert Uytterhoeven wrote:
>>>>> On Thu, 17 Apr 2025 at 11:33, Wolfram Sang
>>>>> <wsa+renesas@sang-engineering.com> wrote:
>>>>>> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>>>>> ---
>>>>>>
>>>>>> Changes since v2:
>>>>>> * using function, color, function-enumerator properties now
>>>>>>
>>>>>> Honestly, this is better than using node names? With V2, the LEDs were
>>>>>> named as in the schematics, now they are called:
>>>>>>
>>>>>> lrwxrwxrwx    1 root     root             0 May 12 12:10 green:programming-0 -> ../../devices/platform/leds/leds/green:programming-0
>>>>>> lrwxrwxrwx    1 root     root             0 May 12 12:10 green:programming-1 -> ../../devices/platform/leds/leds/green:programming-1
>>>>>> lrwxrwxrwx    1 root     root             0 May 12 12:10 green:programming-2 -> ../../devices/platform/leds/leds/green:programming-2
>>>>>> ...
>>>>>>
>>>>>> Which gets even more confusing if we might later add LEDs not on this
>>>>>> board, but on the expansion board. 'green:programming-8' sits where?
>>>>>>
>>>>>> I really wonder, but if this is the official way now...
>>>>>
>>>>> Good point!  So I'm inclined to take v2...
>>>>>
>>>>> Let's raise this with the LED people. I don't want to fight Pavel when
>>>>> v2 hits the CiP tree ;-)
>>>>
>>>> So, if there is no other opinion here, can we remove function, color,
>>>> function-enumerator and just use the node names which match the
>>>> schematics? Basically apply V2?
>>>
>>> I didn't author the semantics nor the rules surrounding them, but I am
>>> obliged to enforce them.  Therefore "LED people" say, please stick to
>>> convention as stated in the present documentation:
>>>
>>> https://docs.kernel.org/leds/leds-class.html#led-device-naming
>>>
>>> Please note that a "debug" (LED_FUNCTION_DEBUG) option already exists if
>>> that is more appropriate to your use-case.
>>>
>>> Let's also bring Jacek into the conversion, since I know that he did a
>>> bunch of work around this topic.
>>
>> The question is if the LED name from the schematics tells anything to
>> the user of the equipment?
> 
> As this is a development board and not a finished product, I would
> answer yes.

OK.

>> The idea behind LED naming is to facilitate matching the LED class
>> device name as reported by the system with the LED location on the
>> equipment.
>>
>> The LED naming standardization intended to enforce consistent
>> LED naming, and not allowing to add multiple interchangeable
>> names like wifi/wlan. It also helps to keep LED name sections order in
>> accordance with Linux documentation, which before had been often
>> abused by allowing to assign anything to the now deprecated 'label'
>> DT property.
> 
> I agree this all makes perfect sense for a final product, where the
> purpose of each LED is clear, and sometimes indicated by an icon
> on the case.
> For a development board, some LEDs may have a fixed purpose.
> But typically there is also a collection of generic user LEDs, which
> do not have a fixed purpose, and are identified by a label on the
> schematics.  Imposing an arbitrary numbering scheme on the latter is
> confusing for the user (developer).

Using DT child node name for LED class device name is only
a last resort fallback. However if it is devboard and we want to have
a reference to the schematics then I'd say it makes sense to take
LED names from DT nodes. What about the colors? Are the LEDs replaceable
or soldered?

>> Regarding expansion boards - we never have control over what
>> LED names DT overlays will define, thus LED core adds numeric suffix to
>> the LED class device name in case of the name clash.
> 
> FTR, the RZN1D400 Expansion Board does not use a DT overlay.
> Linux carries a DTS for it, which just includes the base board .dts,
> and treats it as a single system.

Ack.

-- 
Best regards,
Jacek Anaszewski