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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> wrote:
Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
---
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
