linux-kernel - Re: [RFC PATCH 0/2] leds: Add optional instance identifier for deterministic naming

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <DS0PR84MB3746F2BB2CB8381BA02013059FBFA@DS0PR84MB3746.NAMPRD84.PROD.OUTLOOK.COM>
Date: Mon, 29 Dec 2025 23:59:07 +0000
From: Jonathan Brophy <Professor_jonny@...mail.com>
To: Jacek Anaszewski <jacek.anaszewski@...il.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


>> 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 */
};


// 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