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

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

[Jonathan Brophy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 3842 bytes --]

From: Jonathan Brophy <professor_jonny@hotmail.com>

This patch series introduces an optional "led-instance" device tree property
to address non-deterministic LED naming when multiple LEDs share the same
function and color.

Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
registration order when duplicate function:color combinations exist. This
creates several problems:

1. **Non-deterministic naming**: Registration order determines suffix values,
   which can change across boots due to probe ordering, async initialization,
   or module load order.

2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
   indication of which physical LED or subsystem they represent.

3. **Breaks userspace automation**: Network management tools, LED control
   daemons, and hardware monitoring cannot reliably identify LEDs.

4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
   when it may actually be the 23rd registered LED of any port.

5. **Namespace pollution**: The alternative of adding vendor-specific function
   names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
   function namespace. The instance identifier keeps standard functions clean
   while allowing contextual differentiation.

6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
   collision avoidance workaround, but has become the de facto standard for
   hardware with multiple identical LEDs.

**Example: 48-port network switch**

Current behavior (non-deterministic):
  /sys/class/leds/lan:green      ← Port 0? Unknown
  /sys/class/leds/lan:green_1    ← Could be any port
  /sys/class/leds/lan:green_2    ← Could be any port
  ...
  /sys/class/leds/lan:green_47   ← Could be port 1 due to probe order

Proposed behavior (deterministic):
  /sys/class/leds/lan:green:port0   ← Always port 0
  /sys/class/leds/lan:green:port1   ← Always port 1
  /sys/class/leds/lan:green:port2   ← Always port 2
  ...
  /sys/class/leds/lan:green:port47  ← Always port 47

**Example: Multi-domain power indicators**

Current behavior (non-deterministic):
  /sys/class/leds/power:red      ← Which power source?
  /sys/class/leds/power:red_1    ← Which power source?
  /sys/class/leds/power:red_2    ← Which power source?

Proposed behavior (deterministic):
  /sys/class/leds/power:red:mains    ← Mains power indicator
  /sys/class/leds/power:red:battery  ← Battery power indicator
  /sys/class/leds/power:red:usb      ← USB power indicator

**Design principles:**

- Backward compatible: Instance identifier is optional
- Extends existing convention: function:color becomes function:color:instance
- Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
- Ignored with deprecated "label" property: Avoids conflicts with legacy code

**Alternative solutions considered:**

1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
   "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
   to match physical port labels.

2. Deprecated "label" property: Being actively removed from LED bindings. New
   code should not rely on deprecated APIs.

3. Different function names: LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...
   This pollutes the function namespace with hardware-specific combinations.

This RFC seeks feedback on:
- Property naming: "led-instance" vs "led-subsystem" vs "led-context"
- Implementation approach
- Additional use cases to document

Jonathan Brophy (2):
  leds: core: Add support for led-instance property
  dt-bindings: leds: common: Add led-instance property

 .../devicetree/bindings/leds/common.yaml      | 93 +++++++++++++++++++
 drivers/leds/led-core.c                       | 43 +++++++--
 2 files changed, 126 insertions(+), 10 deletions(-)

--
2.43.0

[RFC PATCH 1/2] leds: core: Add support for led-instance property

[Jonathan Brophy]

From: Jonathan Brophy <professor_jonny@hotmail.com>

Add support for parsing an optional "led-instance" device tree property
that provides a third component in LED naming for deterministic
identification when multiple LEDs share the same function and color.

The led-instance becomes part of the LED name as:
  color:function:instance

This solves the non-deterministic _1, _2 suffix problem for hardware
with many identical LEDs (e.g., 48-port network switches).

Signed-off-by: Jonathan Brophy <professor_jonny@hotmail.com>
---
 drivers/leds/led-core.c | 43 +++++++++++++++++++++++++++++++----------
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 59473f286b31..5a72dbe44303 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -475,7 +475,8 @@ EXPORT_SYMBOL_GPL(led_sysfs_enable);

 static void led_parse_fwnode_props(struct device *dev,
 				   struct fwnode_handle *fwnode,
-				   struct led_properties *props)
+				   struct led_properties *props,
+				   const char **instance)
 {
 	int ret;

@@ -501,7 +502,7 @@ static void led_parse_fwnode_props(struct device *dev,


 	if (!fwnode_property_present(fwnode, "function"))
-		return;
+		goto parse_instance;

 	ret = fwnode_property_read_string(fwnode, "function", &props->function);
 	if (ret) {
@@ -511,7 +512,7 @@ static void led_parse_fwnode_props(struct device *dev,
 	}

 	if (!fwnode_property_present(fwnode, "function-enumerator"))
-		return;
+		goto parse_instance;

 	ret = fwnode_property_read_u32(fwnode, "function-enumerator",
 				       &props->func_enum);
@@ -522,6 +523,14 @@ static void led_parse_fwnode_props(struct device *dev,
 	} else {
 		props->func_enum_present = true;
 	}
+
+parse_instance:
+	/* Parse optional instance identifier */
+	if (fwnode_property_present(fwnode, "led-instance")) {
+		ret = fwnode_property_read_string(fwnode, "led-instance", instance);
+		if (ret)
+			dev_err(dev, "Error parsing 'led-instance' property (%d)\n", ret);
+	}
 }

 int led_compose_name(struct device *dev, struct led_init_data *init_data,
@@ -530,12 +539,13 @@ int led_compose_name(struct device *dev, struct led_init_data *init_data,
 	struct led_properties props = {};
 	struct fwnode_handle *fwnode = init_data->fwnode;
 	const char *devicename = init_data->devicename;
+	const char *instance = NULL;
 	int n;

 	if (!led_classdev_name)
 		return -EINVAL;

-	led_parse_fwnode_props(dev, fwnode, &props);
+	led_parse_fwnode_props(dev, fwnode, &props, &instance);

 	if (props.label) {
 		/*
@@ -554,13 +564,26 @@ int led_compose_name(struct device *dev, struct led_init_data *init_data,
 		char tmp_buf[LED_MAX_NAME_SIZE];

 		if (props.func_enum_present) {
-			n = snprintf(tmp_buf, LED_MAX_NAME_SIZE, "%s:%s-%d",
-				     props.color_present ? led_colors[props.color] : "",
-				     props.function ?: "", props.func_enum);
+			if (instance) {
+				n = snprintf(tmp_buf, LED_MAX_NAME_SIZE, "%s:%s-%d:%s",
+					     props.color_present ? led_colors[props.color] : "",
+					     props.function ?: "", props.func_enum,
+					     instance);
+			} else {
+				n = snprintf(tmp_buf, LED_MAX_NAME_SIZE, "%s:%s-%d",
+					     props.color_present ? led_colors[props.color] : "",
+					     props.function ?: "", props.func_enum);
+			}
 		} else {
-			n = snprintf(tmp_buf, LED_MAX_NAME_SIZE, "%s:%s",
-				     props.color_present ? led_colors[props.color] : "",
-				     props.function ?: "");
+			if (instance) {
+				n = snprintf(tmp_buf, LED_MAX_NAME_SIZE, "%s:%s:%s",
+					     props.color_present ? led_colors[props.color] : "",
+					     props.function ?: "", instance);
+			} else {
+				n = snprintf(tmp_buf, LED_MAX_NAME_SIZE, "%s:%s",
+					     props.color_present ? led_colors[props.color] : "",
+					     props.function ?: "");
+			}
 		}
 		if (n >= LED_MAX_NAME_SIZE)
 			return -E2BIG;
--
2.43.0

Re: [RFC PATCH 1/2] leds: core: Add support for led-instance property

[Andriy Shevencho]

On Mon, Dec 29, 2025 at 07:22:44AM +1300, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
> 
> Add support for parsing an optional "led-instance" device tree property
> that provides a third component in LED naming for deterministic
> identification when multiple LEDs share the same function and color.
> 
> The led-instance becomes part of the LED name as:
>   color:function:instance
> 
> This solves the non-deterministic _1, _2 suffix problem for hardware
> with many identical LEDs (e.g., 48-port network switches).

> +parse_instance:
> +	/* Parse optional instance identifier */
> +	if (fwnode_property_present(fwnode, "led-instance")) {
> +		ret = fwnode_property_read_string(fwnode, "led-instance", instance);
> +		if (ret)
> +			dev_err(dev, "Error parsing 'led-instance' property (%d)\n", ret);
> +	}
>  }

But this will be called unconditionally even if the
function/function-enumerator is present. Wouldn't these be conflicting options?

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH 1/2] leds: core: Add support for led-instance property

[Jonathan Brophy]

>But this will be called unconditionally even if the

>function/function-enumerator is present. Wouldn't these be conflicting options?
>
>--
>
>With Best Regards,
>
>Andy Shevchenko

Good point! You're right that function-enumerator and led-instance could
conflict. I'll make them mutually exclusive.

The semantic difference is:
- function-enumerator: Numeric instances (0, 1, 2...) → "lan:green-5"
- led-instance: Semantic instances ("port23") → "lan:green:port23"

Having both would create "lan:green-5:port23" which is confusing.

I can add validation to reject DT nodes that specify both:

  if (props->func_enum_present && instance) {
      dev_err(dev, "'led-instance' and 'function-enumerator' are mutually exclusive\n");
      return -EINVAL;
  }

And document this in the DT binding:

  "This property cannot be used together with function-enumerator.
   Use function-enumerator for numeric instances (0, 1, 2) or
   led-instance for semantic instances (port0, battery, usb)."

would this be ok ?

Re: [RFC PATCH 1/2] leds: core: Add support for led-instance property

[Andriy Shevencho]

On Sun, Dec 28, 2025 at 06:43:18PM +0000, Jonathan Brophy wrote:
> >But this will be called unconditionally even if the
> 
> >function/function-enumerator is present. Wouldn't these be conflicting options?
> >
> Good point! You're right that function-enumerator and led-instance could
> conflict. I'll make them mutually exclusive.
> 
> The semantic difference is:
> - function-enumerator: Numeric instances (0, 1, 2...) ^[$B"*^[(B "lan:green-5"
> - led-instance: Semantic instances ("port23") ^[$B"*^[(B "lan:green:port23"
> 
> Having both would create "lan:green-5:port23" which is confusing.
> 
> I can add validation to reject DT nodes that specify both:
> 
>   if (props->func_enum_present && instance) {
>       dev_err(dev, "'led-instance' and 'function-enumerator' are mutually exclusive\n");
>       return -EINVAL;
>   }

Dunno. Maybe Lee can comment and/or suggest on this...

> And document this in the DT binding:
> 
>   "This property cannot be used together with function-enumerator.
>    Use function-enumerator for numeric instances (0, 1, 2) or
>    led-instance for semantic instances (port0, battery, usb)."
> 
> would this be ok ?

In DT as far as I know the special syntax is used for the mutually exclusive
properties. But not an expert, better to wait the answer by DT people.

-- 
With Best Regards,
Andy Shevchenko

[RFC PATCH 2/2] dt-bindings: leds: common: Add led-instance property

[Jonathan Brophy]

From: Jonathan Brophy <professor_jonny@hotmail.com>

Document the optional "led-instance" property for providing deterministic
LED naming when multiple LEDs share the same function and color.

Signed-off-by: Jonathan Brophy <professor_jonny@hotmail.com>
---
 .../devicetree/bindings/leds/common.yaml      | 93 +++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index f4e44b33f56d..0e9611662850 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -51,6 +51,33 @@ properties:
       needed, differing only with an ordinal number.
     $ref: /schemas/types.yaml#/definitions/uint32

+  led-instance:
+    description:
+      Optional instance identifier for deterministic LED naming when multiple
+      LEDs share the same function and color. Without this property, the LED
+      core appends numerical suffixes (_1, _2) based on registration order,
+      which is non-deterministic and breaks userspace automation.
+
+      The instance identifier becomes the third component in the LED name
+      using the format "function:color:instance" (or "color:function-N:instance"
+      when function-enumerator is present).
+
+      This property is only used with the modern function and color based naming
+      scheme. It is ignored when the deprecated "label" property is present, as
+      "label" already provides full control over the LED name.
+
+      Common use cases include multi-port network devices ("port0", "port1"),
+      multi-domain power indicators ("battery", "ac", "usb"), and system state
+      LEDs ("boot", "upgrade", "panic").
+
+      The identifier should be semantic (describes purpose), deterministic
+      (fixed in hardware description), and concise (under 32 characters).
+      Only alphanumeric characters, dashes, and underscores are allowed, and
+      the identifier must start with an alphanumeric character.
+    $ref: /schemas/types.yaml#/definitions/string
+    maxLength: 31
+    pattern: "^[a-zA-Z0-9][a-zA-Z0-9_-]*$"
+
   label:
     description:
       The label for this LED. If omitted, the label is taken from the node name
@@ -320,4 +347,70 @@ examples:
         };
     };

+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/leds/common.h>
+
+    /* Example: 48-port network switch with deterministic port LEDs */
+    ethernet-leds {
+        compatible = "gpio-leds";
+
+        led-port0 {
+            function = LED_FUNCTION_LAN;
+            color = <LED_COLOR_ID_GREEN>;
+            led-instance = "port0";
+            gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+            /* Result: /sys/class/leds/green:lan:port0 */
+        };
+
+        led-port1 {
+            function = LED_FUNCTION_LAN;
+            color = <LED_COLOR_ID_GREEN>;
+            led-instance = "port1";
+            gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+            /* Result: /sys/class/leds/green:lan:port1 */
+        };
+
+        led-port47 {
+            function = LED_FUNCTION_LAN;
+            color = <LED_COLOR_ID_GREEN>;
+            led-instance = "port47";
+            gpios = <&gpio0 47 GPIO_ACTIVE_HIGH>;
+            /* Result: /sys/class/leds/green:lan:port47 */
+        };
+    };
+
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/leds/common.h>
+
+    /* Example: Multiple power domain LEDs */
+    power-leds {
+        compatible = "gpio-leds";
+
+        led-ac-power {
+            function = LED_FUNCTION_POWER;
+            color = <LED_COLOR_ID_GREEN>;
+            led-instance = "ac";
+            gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+            /* Result: /sys/class/leds/green:power:ac */
+        };
+
+        led-battery-power {
+            function = LED_FUNCTION_POWER;
+            color = <LED_COLOR_ID_GREEN>;
+            led-instance = "battery";
+            gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+            /* Result: /sys/class/leds/green:power:battery */
+        };
+
+        led-usbc-power {
+            function = LED_FUNCTION_POWER;
+            color = <LED_COLOR_ID_GREEN>;
+            led-instance = "usbc";
+            gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+            /* Result: /sys/class/leds/green:power:usbc */
+        };
+    };
+
 ...
--
2.43.0

Re: [RFC PATCH 2/2] dt-bindings: leds: common: Add led-instance property

[Rob Herring (Arm)]

On Mon, 29 Dec 2025 07:22:45 +1300, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
> 
> Document the optional "led-instance" property for providing deterministic
> LED naming when multiple LEDs share the same function and color.
> 
> Signed-off-by: Jonathan Brophy <professor_jonny@hotmail.com>
> ---
>  .../devicetree/bindings/leds/common.yaml      | 93 +++++++++++++++++++
>  1 file changed, 93 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/common.yaml: properties:led-instance: 'anyOf' conditional failed, one must be fixed:
	'maxLength' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems']
	'type' was expected
	from schema $id: http://devicetree.org/meta-schemas/keywords.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20251228182252.1550173-3-professorjonny98@gmail.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [RFC PATCH 2/2] dt-bindings: leds: common: Add led-instance property

[Krzysztof Kozlowski]

On Mon, Dec 29, 2025 at 07:22:45AM +1300, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
> 
> Document the optional "led-instance" property for providing deterministic
> LED naming when multiple LEDs share the same function and color.

Label already provides that name.

Best regards,
Krzysztof

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

[Andriy Shevencho]

On Mon, Dec 29, 2025 at 07:22:43AM +1300, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
> 
> This patch series introduces an optional "led-instance" device tree property
> to address non-deterministic LED naming when multiple LEDs share the same
> function and color.
> 
> Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
> registration order when duplicate function:color combinations exist. This
> creates several problems:
> 
> 1. **Non-deterministic naming**: Registration order determines suffix values,
>    which can change across boots due to probe ordering, async initialization,
>    or module load order.
> 
> 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
>    indication of which physical LED or subsystem they represent.
> 
> 3. **Breaks userspace automation**: Network management tools, LED control
>    daemons, and hardware monitoring cannot reliably identify LEDs.
> 
> 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
>    when it may actually be the 23rd registered LED of any port.
> 
> 5. **Namespace pollution**: The alternative of adding vendor-specific function
>    names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
>    function namespace. The instance identifier keeps standard functions clean
>    while allowing contextual differentiation.
> 
> 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
>    collision avoidance workaround, but has become the de facto standard for
>    hardware with multiple identical LEDs.
> 
> **Example: 48-port network switch**
> 
> Current behavior (non-deterministic):
>   /sys/class/leds/lan:green      ← Port 0? Unknown
>   /sys/class/leds/lan:green_1    ← Could be any port
>   /sys/class/leds/lan:green_2    ← Could be any port
>   ...
>   /sys/class/leds/lan:green_47   ← Could be port 1 due to probe order
> 
> Proposed behavior (deterministic):
>   /sys/class/leds/lan:green:port0   ← Always port 0
>   /sys/class/leds/lan:green:port1   ← Always port 1
>   /sys/class/leds/lan:green:port2   ← Always port 2
>   ...
>   /sys/class/leds/lan:green:port47  ← Always port 47
> 
> **Example: Multi-domain power indicators**
> 
> Current behavior (non-deterministic):
>   /sys/class/leds/power:red      ← Which power source?
>   /sys/class/leds/power:red_1    ← Which power source?
>   /sys/class/leds/power:red_2    ← Which power source?
> 
> Proposed behavior (deterministic):
>   /sys/class/leds/power:red:mains    ← Mains power indicator
>   /sys/class/leds/power:red:battery  ← Battery power indicator
>   /sys/class/leds/power:red:usb      ← USB power indicator
> 
> **Design principles:**
> 
> - Backward compatible: Instance identifier is optional
> - Extends existing convention: function:color becomes function:color:instance
> - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
> - Ignored with deprecated "label" property: Avoids conflicts with legacy code
> 
> **Alternative solutions considered:**
> 
> 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
>    "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
>    to match physical port labels.
> 
> 2. Deprecated "label" property: Being actively removed from LED bindings. New
>    code should not rely on deprecated APIs.
> 
> 3. Different function names: LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...
>    This pollutes the function namespace with hardware-specific combinations.

> This RFC seeks feedback on:
> - Property naming: "led-instance" vs "led-subsystem" vs "led-context"
> - Implementation approach
> - Additional use cases to document

Hmm... I think the research missed the udev + sysfs approach as done for the
networking devices. Hence the question: do we have enough data in sysfs for
leds to understand their HW connections / semantics?

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Brophy]

>Hmm... I think the research missed the udev + sysfs approach as done for the

>networking devices. Hence the question: do we have enough data in sysfs for

>leds to understand their HW connections / semantics?



>--

>With Best Regards,

>Andy Shevchenko


I looked at that also but I don't see a way of it working with the current led attributes:

**Current LED sysfs attributes:**

For a typical LED, we have:
  /sys/class/leds/lan:green/
    ├── brightness
    ├── max_brightness
    ├── trigger
    └── device -> ../../../gpio-leds  (generic, not port-specific)

The problem is that **there's no stable identifier** that maps to the hardware:
- The device symlink points to the LED controller (e.g., gpio-leds), not the
  specific port/function
- There's no DT path or hardware identifier exposed
- Multiple identical LEDs (lan:green, lan:green_1, lan:green_2) all have
  identical sysfs attributes except their names

I don't think udev can't help here either:

Network devices work because they have unique identifiers:
  - MAC addresses (globally unique)
  - PCI bus addresses (stable per-slot)
  - Device tree paths (but not exposed for LEDs)

LEDs in a run of the mill 48-port switch generally have:
  - Same GPIO controller
  - Same function (LED_FUNCTION_LAN)
  - Same color (LED_COLOR_ID_GREEN)
  - Same trigger options
  - **Nothing unique** except the name

**What we'd need for udev to work:**

We'd need to expose something like:
  /sys/class/leds/lan:green_23/dt_path -> /leds/led-port23
  /sys/class/leds/lan:green_23/hardware_id

But this has problems:
1. Not all platforms use DT (ACPI systems)
2. Adds complexity to LED core for every driver
3. Requires userspace policy to parse and create symlinks
4. Still depends on non-deterministic suffix

The instance identifier solves this with much less effort.

Instead of:
  1. Kernel creates "lan:green_23" (non-deterministic)
  2. Kernel exposes DT path in sysfs
  3. Udev reads DT path
  4. Udev creates symlink "lan-port23" -> "lan:green_23"
  5. Userspace uses symlink

We get:
  1. Kernel creates "lan:green:port23" (deterministic, from DT)
  2. Userspace uses it directly

This is simpler, works on non-DT platforms, and follows the existing
function:color naming convention by extending it rather than working around it.

**Precedent:**

The networking subsystem itself had to solve this with predictable interface
names (enp3s0) because MAC addresses aren't in DT and PCI enumeration order
can change.
With this patch we're solving the same problem, but for LEDs the solution is
simpler: put the identifier in the name from the start.

I don't know of another suitable way to make it work without much change
and from my research it really does not bring much to the table and adds a lot
of complexity when there is a simple solution.

Regards
Jonathan Brophy

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

[Andriy Shevencho]

On Sun, Dec 28, 2025 at 07:14:09PM +0000, Jonathan Brophy wrote:
> >Hmm... I think the research missed the udev + sysfs approach as done for the
> 
> >networking devices. Hence the question: do we have enough data in sysfs for
> 
> >leds to understand their HW connections / semantics?

> I looked at that also but I don't see a way of it working with the current led attributes:

Okay, thanks for the quite an elaboration!
With that in mind I think your approach is okay, but I'm not a maintainer
to make a (final) decision.

-- 
With Best Regards,
Andy Shevchenko

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

[Andriy Shevencho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1120 bytes --]

On Sun, Dec 28, 2025 at 07:14:09PM +0000, Jonathan Brophy wrote:
> >Hmm... I think the research missed the udev + sysfs approach as done for the
> 
> >networking devices. Hence the question: do we have enough data in sysfs for
> 
> >leds to understand their HW connections / semantics?

...

> **What we'd need for udev to work:**
> 
> We'd need to expose something like:
> š /sys/class/leds/lan:green_23/dt_path -> /leds/led-port23
> š /sys/class/leds/lan:green_23/hardware_id
> 
> But this has problems:
> 1. Not all platforms use DT (ACPI systems)

Ah, forgot to comment on this. ACPI incorporates the way of key=value
properties in the similar way DT does. So it's not a good point.

> 2. Adds complexity to LED core for every driver
> 3. Requires userspace policy to parse and create symlinks

This is what udev is for.

> 4. Still depends on non-deterministic suffix

Same as #3.

So, this leaves us only #2. Which is a weak argument in my opinion.

> The instance identifier solves this with much less effort.

But as I already replied, your approach is also okay to me.

-- 
With Best Regards,
Andy Shevchenko

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

[Jacek Anaszewski]

Hi Jonathan,

On 12/28/25 19:22, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
> 
> This patch series introduces an optional "led-instance" device tree property
> to address non-deterministic LED naming when multiple LEDs share the same
> function and color.
> 
> Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
> registration order when duplicate function:color combinations exist. This
> creates several problems:
> 
> 1. **Non-deterministic naming**: Registration order determines suffix values,
>     which can change across boots due to probe ordering, async initialization,
>     or module load order.
> 
> 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
>     indication of which physical LED or subsystem they represent.
> 
> 3. **Breaks userspace automation**: Network management tools, LED control
>     daemons, and hardware monitoring cannot reliably identify LEDs.
> 
> 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
>     when it may actually be the 23rd registered LED of any port.
> 
> 5. **Namespace pollution**: The alternative of adding vendor-specific function
>     names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
>     function namespace. The instance identifier keeps standard functions clean
>     while allowing contextual differentiation.
> 
> 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
>     collision avoidance workaround, but has become the de facto standard for
>     hardware with multiple identical LEDs.
> 
> **Example: 48-port network switch**
> 
> Current behavior (non-deterministic):
>    /sys/class/leds/lan:green      ← Port 0? Unknown
>    /sys/class/leds/lan:green_1    ← Could be any port
>    /sys/class/leds/lan:green_2    ← Could be any port
>    ...
>    /sys/class/leds/lan:green_47   ← Could be port 1 due to probe order
> 
> Proposed behavior (deterministic):
>    /sys/class/leds/lan:green:port0   ← Always port 0
>    /sys/class/leds/lan:green:port1   ← Always port 1
>    /sys/class/leds/lan:green:port2   ← Always port 2
>    ...
>    /sys/class/leds/lan:green:port47  ← Always port 47
> 
> **Example: Multi-domain power indicators**
> 
> Current behavior (non-deterministic):
>    /sys/class/leds/power:red      ← Which power source?
>    /sys/class/leds/power:red_1    ← Which power source?
>    /sys/class/leds/power:red_2    ← Which power source?
> 
> Proposed behavior (deterministic):
>    /sys/class/leds/power:red:mains    ← Mains power indicator
>    /sys/class/leds/power:red:battery  ← Battery power indicator
>    /sys/class/leds/power:red:usb      ← USB power indicator
> 
> **Design principles:**
> 
> - Backward compatible: Instance identifier is optional
> - Extends existing convention: function:color becomes function:color:instance
> - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
> - Ignored with deprecated "label" property: Avoids conflicts with legacy code
> 
> **Alternative solutions considered:**
> 
> 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
>     "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
>     to match physical port labels.

I think that we have currently everything in place to address the issue
you're trying to solve with this patch. Just introduce dedicated
function like LAN_PORT, and exploit function-enumerator.

-- 
Best regards,
Jacek Anaszewski

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

[Andriy Shevencho]

On Mon, Dec 29, 2025 at 12:16:17PM +0100, Jacek Anaszewski wrote:
> On 12/28/25 19:22, Jonathan Brophy wrote:

> > This patch series introduces an optional "led-instance" device tree property
> > to address non-deterministic LED naming when multiple LEDs share the same
> > function and color.
> > 
> > Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
> > registration order when duplicate function:color combinations exist. This
> > creates several problems:
> > 
> > 1. **Non-deterministic naming**: Registration order determines suffix values,
> >     which can change across boots due to probe ordering, async initialization,
> >     or module load order.
> > 
> > 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
> >     indication of which physical LED or subsystem they represent.
> > 
> > 3. **Breaks userspace automation**: Network management tools, LED control
> >     daemons, and hardware monitoring cannot reliably identify LEDs.
> > 
> > 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
> >     when it may actually be the 23rd registered LED of any port.
> > 
> > 5. **Namespace pollution**: The alternative of adding vendor-specific function
> >     names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
> >     function namespace. The instance identifier keeps standard functions clean
> >     while allowing contextual differentiation.
> > 
> > 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
> >     collision avoidance workaround, but has become the de facto standard for
> >     hardware with multiple identical LEDs.
> > 
> > **Example: 48-port network switch**
> > 
> > Current behavior (non-deterministic):
> >    /sys/class/leds/lan:green      ← Port 0? Unknown
> >    /sys/class/leds/lan:green_1    ← Could be any port
> >    /sys/class/leds/lan:green_2    ← Could be any port
> >    ...
> >    /sys/class/leds/lan:green_47   ← Could be port 1 due to probe order
> > 
> > Proposed behavior (deterministic):
> >    /sys/class/leds/lan:green:port0   ← Always port 0
> >    /sys/class/leds/lan:green:port1   ← Always port 1
> >    /sys/class/leds/lan:green:port2   ← Always port 2
> >    ...
> >    /sys/class/leds/lan:green:port47  ← Always port 47
> > 
> > **Example: Multi-domain power indicators**
> > 
> > Current behavior (non-deterministic):
> >    /sys/class/leds/power:red      ← Which power source?
> >    /sys/class/leds/power:red_1    ← Which power source?
> >    /sys/class/leds/power:red_2    ← Which power source?
> > 
> > Proposed behavior (deterministic):
> >    /sys/class/leds/power:red:mains    ← Mains power indicator
> >    /sys/class/leds/power:red:battery  ← Battery power indicator
> >    /sys/class/leds/power:red:usb      ← USB power indicator
> > 
> > **Design principles:**
> > 
> > - Backward compatible: Instance identifier is optional
> > - Extends existing convention: function:color becomes function:color:instance
> > - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
> > - Ignored with deprecated "label" property: Avoids conflicts with legacy code
> > 
> > **Alternative solutions considered:**
> > 
> > 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
> >     "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
> >     to match physical port labels.
> 
> I think that we have currently everything in place to address the issue
> you're trying to solve with this patch. Just introduce dedicated
> function like LAN_PORT, and exploit function-enumerator.

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?

-- 
With Best Regards,
Andy Shevchenko

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

[Jacek Anaszewski]

On 12/29/25 13:30, Andriy Shevencho wrote:
> On Mon, Dec 29, 2025 at 12:16:17PM +0100, Jacek Anaszewski wrote:
>> On 12/28/25 19:22, Jonathan Brophy wrote:
> 
>>> This patch series introduces an optional "led-instance" device tree property
>>> to address non-deterministic LED naming when multiple LEDs share the same
>>> function and color.
>>>
>>> Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
>>> registration order when duplicate function:color combinations exist. This
>>> creates several problems:
>>>
>>> 1. **Non-deterministic naming**: Registration order determines suffix values,
>>>      which can change across boots due to probe ordering, async initialization,
>>>      or module load order.
>>>
>>> 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
>>>      indication of which physical LED or subsystem they represent.
>>>
>>> 3. **Breaks userspace automation**: Network management tools, LED control
>>>      daemons, and hardware monitoring cannot reliably identify LEDs.
>>>
>>> 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
>>>      when it may actually be the 23rd registered LED of any port.
>>>
>>> 5. **Namespace pollution**: The alternative of adding vendor-specific function
>>>      names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
>>>      function namespace. The instance identifier keeps standard functions clean
>>>      while allowing contextual differentiation.
>>>
>>> 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
>>>      collision avoidance workaround, but has become the de facto standard for
>>>      hardware with multiple identical LEDs.
>>>
>>> **Example: 48-port network switch**
>>>
>>> Current behavior (non-deterministic):
>>>     /sys/class/leds/lan:green      ← Port 0? Unknown
>>>     /sys/class/leds/lan:green_1    ← Could be any port
>>>     /sys/class/leds/lan:green_2    ← Could be any port
>>>     ...
>>>     /sys/class/leds/lan:green_47   ← Could be port 1 due to probe order
>>>
>>> Proposed behavior (deterministic):
>>>     /sys/class/leds/lan:green:port0   ← Always port 0
>>>     /sys/class/leds/lan:green:port1   ← Always port 1
>>>     /sys/class/leds/lan:green:port2   ← Always port 2
>>>     ...
>>>     /sys/class/leds/lan:green:port47  ← Always port 47
>>>
>>> **Example: Multi-domain power indicators**
>>>
>>> Current behavior (non-deterministic):
>>>     /sys/class/leds/power:red      ← Which power source?
>>>     /sys/class/leds/power:red_1    ← Which power source?
>>>     /sys/class/leds/power:red_2    ← Which power source?
>>>
>>> Proposed behavior (deterministic):
>>>     /sys/class/leds/power:red:mains    ← Mains power indicator
>>>     /sys/class/leds/power:red:battery  ← Battery power indicator
>>>     /sys/class/leds/power:red:usb      ← USB power indicator
>>>
>>> **Design principles:**
>>>
>>> - Backward compatible: Instance identifier is optional
>>> - Extends existing convention: function:color becomes function:color:instance
>>> - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
>>> - Ignored with deprecated "label" property: Avoids conflicts with legacy code
>>>
>>> **Alternative solutions considered:**
>>>
>>> 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
>>>      "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
>>>      to match physical port labels.
>>
>> I think that we have currently everything in place to address the issue
>> you're trying to solve with this patch. Just introduce dedicated
>> function like LAN_PORT, and exploit function-enumerator.
> 
> 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

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

[Andriy Shevencho]

On Mon, Dec 29, 2025 at 03:28:20PM +0100, Jacek Anaszewski wrote:
> On 12/29/25 13:30, Andriy Shevencho wrote:
> > On Mon, Dec 29, 2025 at 12:16:17PM +0100, Jacek Anaszewski wrote:
> > > On 12/28/25 19:22, Jonathan Brophy wrote:
> > 
> > > > This patch series introduces an optional "led-instance" device tree property
> > > > to address non-deterministic LED naming when multiple LEDs share the same
> > > > function and color.
> > > > 
> > > > Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
> > > > registration order when duplicate function:color combinations exist. This
> > > > creates several problems:
> > > > 
> > > > 1. **Non-deterministic naming**: Registration order determines suffix values,
> > > >      which can change across boots due to probe ordering, async initialization,
> > > >      or module load order.
> > > > 
> > > > 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
> > > >      indication of which physical LED or subsystem they represent.
> > > > 
> > > > 3. **Breaks userspace automation**: Network management tools, LED control
> > > >      daemons, and hardware monitoring cannot reliably identify LEDs.
> > > > 
> > > > 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
> > > >      when it may actually be the 23rd registered LED of any port.
> > > > 
> > > > 5. **Namespace pollution**: The alternative of adding vendor-specific function
> > > >      names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
> > > >      function namespace. The instance identifier keeps standard functions clean
> > > >      while allowing contextual differentiation.
> > > > 
> > > > 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
> > > >      collision avoidance workaround, but has become the de facto standard for
> > > >      hardware with multiple identical LEDs.
> > > > 
> > > > **Example: 48-port network switch**
> > > > 
> > > > Current behavior (non-deterministic):
> > > >     /sys/class/leds/lan:green      ← Port 0? Unknown
> > > >     /sys/class/leds/lan:green_1    ← Could be any port
> > > >     /sys/class/leds/lan:green_2    ← Could be any port
> > > >     ...
> > > >     /sys/class/leds/lan:green_47   ← Could be port 1 due to probe order
> > > > 
> > > > Proposed behavior (deterministic):
> > > >     /sys/class/leds/lan:green:port0   ← Always port 0
> > > >     /sys/class/leds/lan:green:port1   ← Always port 1
> > > >     /sys/class/leds/lan:green:port2   ← Always port 2
> > > >     ...
> > > >     /sys/class/leds/lan:green:port47  ← Always port 47
> > > > 
> > > > **Example: Multi-domain power indicators**
> > > > 
> > > > Current behavior (non-deterministic):
> > > >     /sys/class/leds/power:red      ← Which power source?
> > > >     /sys/class/leds/power:red_1    ← Which power source?
> > > >     /sys/class/leds/power:red_2    ← Which power source?
> > > > 
> > > > Proposed behavior (deterministic):
> > > >     /sys/class/leds/power:red:mains    ← Mains power indicator
> > > >     /sys/class/leds/power:red:battery  ← Battery power indicator
> > > >     /sys/class/leds/power:red:usb      ← USB power indicator
> > > > 
> > > > **Design principles:**
> > > > 
> > > > - Backward compatible: Instance identifier is optional
> > > > - Extends existing convention: function:color becomes function:color:instance
> > > > - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
> > > > - Ignored with deprecated "label" property: Avoids conflicts with legacy code
> > > > 
> > > > **Alternative solutions considered:**
> > > > 
> > > > 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
> > > >      "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
> > > >      to match physical port labels.
> > > 
> > > I think that we have currently everything in place to address the issue
> > > you're trying to solve with this patch. Just introduce dedicated
> > > function like LAN_PORT, and exploit function-enumerator.
> > 
> > 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.

Ah, that's nice!

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Brophy]

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

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

[Jacek Anaszewski]

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