Hi Jacek, Thanks for your answer! 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. > 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). > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
