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

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

On 5/15/25 08:53, Lee Jones wrote:
> On Wed, 14 May 2025, Jacek Anaszewski wrote:
> 
>> On 5/14/25 17:28, Lee Jones wrote:
>>> On Mon, 12 May 2025, Jacek Anaszewski wrote:
>>>
>>>> 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?
>>>
>>> Looks like this option does what you want:
>>>
>>> https://github.com/torvalds/linux/blob/master/drivers/leds/led-core.c#L578
>>>
>>> For this to execute you need to provide init_data when calling
>>> *led_classdev_register*(), omit the; label, function, color_present DT
>>> properties and also init_data's default_label attribute.  At which point
>>> the DT node name should be taken as the LED class name.
>>
>> Yep, I know how it works, I wrote that code after all.
> 
> Sorry for the ambiguity.  I was attempting to address Wolfram.

No problem.

>> Here, I wanted to clarify whether it wouldn't make sense to stick to
>> the approach with 'function' and 'color' properties if LEDs are fixed
>> on the board and the colors are known.
>>
>>  From [0] I infer that LEDs are green, so we should use 'color' DT
>> property definitely. And as a 'function' we can assign plain text "pcaN"
>> if you feel it makes sense for that board.
> 
> The 'function' documentation specifically says to use one of the
> predefined LED_FUNCTION_* entries.  If we are officially accepting
> caveats to that, we should probably update it.

We could add a note saying that if required function name is unlikely
to be reused in other devices, then it is acceptable to use custom
string.

-- 
Best regards,
Jacek Anaszewski