Linux LED subsystem development
 help / color / mirror / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Lee Jones <lee@kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-renesas-soc@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, Pavel Machek <pavel@kernel.org>,
	linux-leds <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v3] ARM: dts: renesas: r9a06g032-rzn1d400-db: describe Debug LEDs
Date: Sat, 10 May 2025 14:43:45 +0200	[thread overview]
Message-ID: <18b78845-3f01-444d-835a-aa39f84a2689@gmail.com> (raw)
In-Reply-To: <20250508134930.GM3865826@google.com>

Hi all,

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:
>>> Hi Wolfram,
>>>
>>> CC leds
>>>
>>> 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?

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.

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.

-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2025-05-10 12:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250417093256.40390-2-wsa+renesas@sang-engineering.com>
2025-04-17 11:39 ` [PATCH v3] ARM: dts: renesas: r9a06g032-rzn1d400-db: describe Debug LEDs Geert Uytterhoeven
2025-05-08  7:56   ` Wolfram Sang
2025-05-08 13:49     ` Lee Jones
2025-05-10 12:43       ` Jacek Anaszewski [this message]
2025-05-12  7:13         ` Geert Uytterhoeven
2025-05-12 17:54           ` Jacek Anaszewski
2025-05-14 15:28             ` Lee Jones
2025-05-14 18:57               ` Jacek Anaszewski
2025-05-15  6:53                 ` Lee Jones
2025-05-15 20:14                   ` Jacek Anaszewski
2025-05-15  8:27                 ` Wolfram Sang
2025-05-15  9:15                   ` Lee Jones
2025-05-15 19:53                   ` Jacek Anaszewski
2025-05-16  7:35         ` Alexander Dahl
2025-05-18 14:36           ` Jacek Anaszewski
2025-05-19  7:37             ` Alexander Dahl
2025-05-19 21:14               ` Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18b78845-3f01-444d-835a-aa39f84a2689@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=pavel@kernel.org \
    --cc=robh@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox