Message-ID: <8022bcc7-c47d-44f8-b5b0-d2ff74ad9efd@gmail.com>
Date: Tue, 30 Dec 2025 17:35:52 +0100
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Jonathan Brophy <Professor_jonny@...mail.com>,
 Andriy Shevencho <andriy.shevchenko@...ux.intel.com>
Cc: Jonathan Brophy <professorjonny98@...il.com>, lee Jones <lee@...nel.org>,
 Pavel Machek <pavel@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Radoslav Tsvetkov <rtsvetkov@...dotech.eu>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] leds: Add optional instance identifier for
 deterministic naming



On 12/30/25 00:59, Jonathan Brophy wrote:
> 
>>> The problem as I understood not exactly in this. The reporter wants
>>> deterministic way of the mapping between HW numbered LEDs and their respective
>>> names. It seems it was already mentioned that current code depends on the
>>> arbitrary probe ordering. Saying this, I now think that perhaps GPIO led driver
>>> should somehow allocate a range of the LEDs and then enumerate them in
> 
>> accordance with the DT description?
> 
> 
>> function-enumerator DT property enables deterministic enumeration.
> 
> 
>> --
>> Best regards,
>> Jacek Anaszewski
> 
> That's not really the the problem I'm trying to solve but it is part of it.
> The functions are quite ambiguous at the moment.
> Having a string that  can define something custom, the fallback _1 _2 identifiers are
> high lighting the issue because the lack of options.
> 
> I have a virtual led grouping driver that this restriction will highlight the issue even more.
> with a status led on a typical oem device that indicate multiple states eg:
> 
>   - Solid Blue: setting up/ committing settings change.
>   - Pulse Blue: factory reset/ first boot ready for setup or WPS in progress.
>   - Fade in-out Blue: system upgrade in progress
>   - Solid Yellow: starting up.*/
>   - pulse Yellow: resetting/ rebooting.*/
> 
>  From sysfs i will end up with the below that really does not explain the use:
> 
> led:status:blue
> led:status:blue_1
> led:ststus:blue_2
> led:status:yellow
> led:status:yellow_1
> 
> The LED subsystem has a semantic ambiguity:
> What does LED_FUNCTION_LAN actually mean?
> LAN port exists?
> LAN cable connected?
> LAN link active?
> LAN traffic activity?
> LAN speed indicator?
> 
> Rather than making custom identifiers that are overly specific we could make
> them up from stacking qualifiers or include a custom string to add meaning.
> Would this be preferable over filling the common.h with long time gone
> devices past identifiers that are overly specific to that platform or device? we
> already have a few of them now.
> 
> Something like this:
> 
> led-lan-link {
>      function = LED_FUNCTION_LAN;
>      function-qualifier = "link-speed";  // NEW PROPERTY
>      color = <LED_COLOR_ID_GREEN>;
>      led-instance = "port5";
>      /* Result: green:lan-link-speed:port5 */
> };
> 
> led-cellular-signal {
>      function = LED_FUNCTION_WLAN;  // or new LED_FUNCTION_CELLULAR
>      function-qualifier = "signal-strength";
>      color = <LED_COLOR_ID_GREEN>;
>      led-instance = "modem0";
>      /* Result: green:wlan-signal-strength:modem0 */
> };

LED naming standardization was introduced to avoid multiplication of
custom LED names for the same functionality. Allowing to define parts
of LED function in plain text would bring back that old problem.

Both function-qualifier and led-instance are not telling anything at
first glance. Their purpose would be to define meaningful LED function
name, thus we should rather think of introducing more advanced mechanism
for composing LED function name, instead of extending the LED naming
pattern.

That could be preprocessor macros that would concatenate standard LED
function name segments that would be still defined in common.h, which
would allow to keep the standardization.

Below example shows how some of your exemplary LED names could be
created with that (for numerical postfixes function-enumerator would
have to employed in addition to those):

// These ones already exist in common.h
#define LED_FUNCTION_WLAN "wlan"
#define LED_FUNCTION_LAN "lan"
#define LED_FUNCTION_INDICATOR "indicator"

#define LED_FUNCTION_PORT "port"
#define LED_FUNCTION_CABLE "cable"
#define LED_FUNCTION_CONNECTED "connected"
#define LED_FUNCTION_CABLE "cable"
#define LED_FUNCTION_LINK "link"
#define LED_FUNCTION_TRAFFIC "traffic"
#define LED_FUNCTION_SPEED "speed"
#define LED_FUNCTION_SIGNAL "signal"
#define LED_FUNCTION_STRENGTH "strength"
#define LED_FUNCTION_MODEM "modem"

#define MAKE_LED_FUNCTION2(seg1, seg2) seg1"-"seg2
#define MAKE_LED_FUNCTION3(seg1, seg2, seg3) seg1"-"seg2"-"seg3
#define MAKE_LED_FUNCTION4(seg1, seg2, seg3, seg4) seg1"-"seg2"-"seg3"-"seg4

Then, when called as below:

MAKE_LED_FUNCTION3(LED_FUNCTION_LAN, LED_FUNCTION_CABLE, 
LED_FUNCTION_CONNECTED)
MAKE_LED_FUNCTION3(LED_FUNCTION_WLAN, LED_FUNCTION_SPEED, 
LED_FUNCTION_INDICATOR)
MAKE_LED_FUNCTION4(LED_FUNCTION_WLAN, LED_FUNCTION_SIGNAL, 
LED_FUNCTION_STRENGTH, LED_FUNCTION_MODEM)
MAKE_LED_FUNCTION4(LED_FUNCTION_LAN, LED_FUNCTION_LINK, 
LED_FUNCTION_SPEED, LED_FUNCTION_PORT)

would produce below:

lan-cable-connected
wlan-speed-indicator
wlan-signal-strength-modem
lan-link-speed-port



> // Network qualifiers
> "link"         // Cable connected
> "activity"     // Data transfer
> "speed"        // Link speed indication
> "duplex"       // Full/half duplex
> "mesh"         // Mesh node
> 
> // Cellular qualifiers
> "signal"       // Signal strength
> "activity"     // Data activity
> "registered"   // Registered to network
> "roaming"      // Roaming status
> 
> // Power qualifiers
> "charging"     // Battery charging
> "low"          // Low battery warning
> "present"      // Power source present
> 
> I'm just really trying to find a way to make the naming more descriptive and I'm
> open to suggestions.
> 
> regards Jonathan Brophy
> 
> 

-- 
Best regards,
Jacek Anaszewski

Powered by blists - more mailing lists