leds: Add a virtual LED driver for groups of

From: Jonathan Brophy <[email protected]>

Introduce a new driver that implements virtual LED groups, aggregating multiple monochromatic LEDs into virtual groups and providing priority-based control for concurrent state management.

Existing multi-LED drivers are primarily intended to group monochrome LEDs into multicolor LEDs, allowing per-channel intensity control of hue and brightness. However, they are not designed to manage grouped LEDs with independent functional roles or shared behavior.

The leds-group-virtualcolor driver allows arbitrary LEDs to be grouped and exposed as a single logical LED representing a fixed color, status, or function. Properties such as triggers and brightness are applied to the group as a whole, rather than to individual LED elements.

This is particularly useful in consumer devices (e.g., routers), where a single status LED must reflect multiple device states via color or blink patterns. In such cases, simple device tree bindings are insufficient, as multiple triggers may activate simultaneously, resulting in color mixing and ambiguous status indication.

To avoid this problem, the driver implements a priority mechanism that allows higher-priority LEDs to assume control of the group. When multiple LEDs of the same priority are active concurrently, the most recently activated LED takes precedence over earlier ones. If a higher-priority LED is extinguished, a lower- priority LED will become active.
If an LED is set to blink, or is controlled with an on or off delay, any time the LED is inactive but still triggered, it will be the only LED in control and will be extinguished during this time for best contrast.

leds-group-virtualcolor can also enable decomposition of multi-element multicolor LEDs into individual virtual groups that can provide individual virtual color LEDs, supporting flexible trigger assignments and precise status representation.

leds-group-virtualcolor can join PWM LEDs into the group with their own bindings for each primary color this enables per channel dimming and fine tuning of color of the grouped PWM LEDs.

PWM and monochromatic LEDs can be joined into the same groups sharing the same grouped global brightness controls.

leds-group-virtualcolor can also expose a singular LED as multiple virtual LEDs, each having individual triggers, timings, or other properties.

Additionally, traditional bindings can only control individual LED elements, making it impossible to represent composite colors formed by combinations of primary RGB components but this is also made possible.

Originally intended to be used with OpenWrt for controlling RGB status LEDs so control of power, reboot and system upgrade cam mimic the manufactures status LED mixed colors.
Often when a device ported to OpenWrt RGB status LEDs usually became a glorified power-led instead of a status led because user scripts or binaries would have to be implemented as additional packages to control logic.

leds-group-virtualcolor is designed to allow LED behavior to be fully described and logically controlled in the device tree, enabling early status indication during system initialization—without relying on user-space scripts or custom binaries.

Jonathan Brophy (4):
dt: bindings: Add virtualcolor class dt bindings
dt-bindings: leds: Add virtualcolor group dt bindings documentation.
ABI: Add sysfs documentation for leds-group-virtualcolor
Subject: [PATCH v3 4/4] leds: Add virtualcolor LED group driver

 .../ABI/testing/sysfs-class-leds-virtualcolor |  89 +++
 .../leds/leds-class-virtualcolor.yaml         |  90 +++
 .../leds/leds-group-virtualcolor.yaml         | 110 ++++
 drivers/leds/rgb/Kconfig                      |  17 +
 drivers/leds/rgb/Makefile                     |   1 +
 drivers/leds/rgb/leds-group-virtualcolor.c    | 513 ++++++++++++++++++
 include/dt-bindings/leds/common.h             |   4 +
 7 files changed, 824 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-leds-virtualcolor
 create mode 100644 Documentation/devicetree/bindings/leds/leds-class-virtualcolor.yaml
 create mode 100644 Documentation/devicetree/bindings/leds/leds-group-virtualcolor.yaml
 create mode 100644 drivers/leds/rgb/leds-group-virtualcolor.c

--
2.43.0

From: Jonathan Brophy <[email protected]>

Add DT bindings for the LEDs virtualcolor class framework. Add LED-FUNCTION-VIRTUAL-STATUS ID to the FUNCTION ID list for device tree bindings.

---
 .../leds/leds-class-virtualcolor.yaml         | 90 +++++++++++++++++++
 include/dt-bindings/leds/common.h             |  4 +
 2 files changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-class-virtualcolor.yaml

new file mode 100644
index 000000000000..8cbbbf0d746c
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-class-virtualcolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: virtualcolor LED class
+
+maintainers:
+  - Radoslav Tsvetkov <[email protected]>
+
+description: |
+  Validates individual virtual LED nodes that aggregate multiple monochromatic
+  or PWM LEDs.
+
+properties:
+  $nodename:
+    pattern: "^virtual-led(@[0-9a-f])?$"
+
+  reg:
+    maxItems: 1
+    description: Virtual LED index/number
+
+  function:
+    description: |
+      LED function. It is recommended to use LED_FUNCTION_VIRTUAL_STATUS
+      for virtual LEDs to distinguish them from physical LEDs.
+      See: include/dt-bindings/leds/common.h
+
+  color:
+    description: |
+      LED color identifier from the LED_COLOR_ID_* namespace.
+      See: include/dt-bindings/leds/common.h
+
+  leds:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    minItems: 1
+    maxItems: 15
+    description: |
+      Array of phandles to monochromatic LEDs that compose this virtual LED.
+
+  pwm-leds-red:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    minItems: 1
+    maxItems: 15
+    description: |
+      Array of phandles to PWM-controlled red LEDs that compose this virtual
+      LED.
+
+  pwm-leds-green:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    minItems: 1
+    maxItems: 15
+    description: |
+      Array of phandles to PWM-controlled green LEDs that compose this virtual
+      LED.
+
+  pwm-leds-blue:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    minItems: 1
+    maxItems: 15
+    description: |
+      Array of phandles to PWM-controlled blue LEDs that compose this virtual
+      LED.
+
+  priority:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    default: 0
+    description: |
+      Priority level for this virtual LED. Higher values take precedence
+      when multiple virtual LEDs are active simultaneously.
+
+required:
+  - reg
+
+anyOf:
+  - required:
+      - leds
+  - required:
+      - pwm-leds-red
+  - required:
+      - pwm-leds-green
+  - required:
+      - pwm-leds-blue
+
+allOf:
+  - $ref: common.yaml#
+
+additionalProperties: true
+...

index 4f017bea0123..39c34d585a47 100644
@@ -63,6 +63,10 @@
      "lp5523:{r,g,b}" (Nokia N900) */
 #define LED_FUNCTION_STATUS "status"
 
+/* Virtual system LEDs Used for virtual LED groups, multifunction RGB
+	 indicators or status LEDs that reflect complex system states */
+#define LED_FUNCTION_VIRTUAL_STATUS "virtual-status"
+
 #define LED_FUNCTION_MICMUTE "micmute"
 #define LED_FUNCTION_MUTE "mute"
 

--
2.43.0

Why? What part of hardware or real system use case is being solved here?

That's not a proper tag. See submitting patches.

Please use subject prefixes matching the subsystem. You can get them for example with git log --oneline -- DIRECTORY_OR_FILE on the directory your patch is touching. For bindings, the preferred subjects are explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters

I don't understand what is happening with your patchset. It is being changed in unexpected way, like something previously correct - like subject - now is changed for some unexplained reason.

From: Jonathan Brophy <[email protected]>

Add device tree binding documentation for the virtual LED group driver that implements virtual LED groups by aggregating multiple monochromatic LEDs

Bindings for the virtual driver are not describing hardware LEDs they describe virtual devices made from groups of hardware LEDs created from an array of LED phandles.

Normally the device tree is used to describe hardware not virtual hardware but it is particularly useful in situations where you require an LED to be a specific color by mixing primary colors, such as multi element multi color LEDs to be operated from a device tree binding.

It also becomes useful with multiple LEDs operating the same indicator such as ring of light indicators where the LEDs are driven From different GPIO outputs unifying the control that can give basic indication during system startup, shutdown upgrade etc...

---
 .../leds/leds-group-virtualcolor.yaml         | 110 ++++++++++++++++++
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-group-virtualcolor.yaml

new file mode 100644
index 000000000000..f638bdd4d65e
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-group-virtualcolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: virtualcolor LED group driver
+maintainers:
+  - Radoslav Tsvetkov <[email protected]>
+description: |
+  Implements virtual LED groups by aggregating multiple monochromatic LEDs.
+  Provides priority-based control for managing concurrent LED activation requests,
+  ensuring only the highest-priority LED state is active at any given time.
+properties:
+  compatible:
+    const: leds-group-virtualcolor
+  '#address-cells':
+    const: 1
+  '#size-cells':
+    const: 0
+patternProperties:
+  "^virtual":
+    $ref: leds-class-virtualcolor.yaml#
+required:
+  - compatible
+additionalProperties: false
+examples:
+  - |
+    #include <dt-bindings/leds/common.h>
+    #include <dt-bindings/gpio/gpio.h>
+
+    led-controller {
+        compatible = "gpio-leds";
+        led_red: led_red {
+            gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
+            default-state = "off";
+        };
+        led_green: led_green {
+            gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
+            default-state = "off";
+        };
+        led_blue: led_blue {
+            gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+            default-state = "off";
+        };
+    };
+
+    pwm-led-controller {
+        compatible = "pwm-leds";
+
+        led_1: led-1 {
+            color = <LED_COLOR_ID_RED>;
+            pwms = <&twl_pwm 0 7812500>;
+        };
+
+        led_2: led-2 {
+            color = <LED_COLOR_ID_GREEN>;
+            pwms = <&twl_pwmled 0 7812500>;
+        };
+
+        led_3: led-3 {
+            color = <LED_COLOR_ID_RED>;
+            pwms = <&twl_pwm 0 7812500>;
+        };
+
+        led_4: led-4 {
+            color = <LED_COLOR_ID_GREEN>;
+            pwms = <&twl_pwmled 0 7812500>;
+        };
+
+    };
+
+    virtual-led-controller {
+        compatible = "leds-group-virtualcolor";
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        virtual_red@0 {
+            reg = <0>;
+            function = LED_FUNCTION_VIRTUAL_STATUS;
+            color = <LED_COLOR_ID_RED>;
+            leds = <&led_red>;
+            priority = <2>;
+        };
+
+        virtual_yellow_mix@1 {
+            reg = <1>;
+            function = LED_FUNCTION_VIRTUAL_STATUS;
+            color = <LED_COLOR_ID_YELLOW>;
+            leds = <&led_green &led_red>;
+            pwm-leds-red = <&led_1 &led_2>;
+            pwm-leds-green = <&led_1 &led_3>;
+            priority = <1>;
+        };
+
+        virtual_white@2 {
+            reg = <2>;
+            function = LED_FUNCTION_VIRTUAL_STATUS;
+            color = <LED_COLOR_ID_WHITE>;
+            leds = <&led_red &led_green &led_blue>;
+            priority = <15>;
+        };
+
+        virtual_pwm_red@3 {
+            reg = <3>;
+            function = LED_FUNCTION_VIRTUAL_STATUS;
+            color = <LED_COLOR_ID_RED>;
+            pwm-leds-red = <&led_1 &led_3>;
+            priority = <1>;
+        };
+    };

--
2.43.0

Don't describe DT syntax, but hardware. Phandles are not important here. How the board, system looks like? What are you achieving here?

Please describe the hardware and usecase, and then say how existing bindings cannot cover it so binding solves that use case. Write concise, yet informative statements. We all now how DT works, this you do not have to explain to us.

But we need to know WHY we want this code.

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/leds-group-virtualcolor.example.dtb: pwm-led-controller (pwm-leds): led-1: 'max-brightness' is a required property
from schema $id: http://devicetree.org/schemas/leds/leds-pwm.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/leds-group-virtualcolor.example.dtb: pwm-led-controller (pwm-leds): led-2: 'max-brightness' is a required property
from schema $id: http://devicetree.org/schemas/leds/leds-pwm.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/leds-group-virtualcolor.example.dtb: pwm-led-controller (pwm-leds): led-3: 'max-brightness' is a required property
from schema $id: http://devicetree.org/schemas/leds/leds-pwm.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/leds/leds-group-virtualcolor.example.dtb: pwm-led-controller (pwm-leds): led-4: 'max-brightness' is a required property
from schema $id: http://devicetree.org/schemas/leds/leds-pwm.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]

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.

sorry this was me checking my yaml's without validating the whole structure as those are covered by their own Yaml's In futurre I will validate the whole structure.

From: Jonathan Brophy <[email protected]>

Document the sysfs ABI for the Virtual Color LED Group Driver, including brightness control, priority levels, per-color PWM control, and monochromatic LED diagnostic attributes.

---
 .../ABI/testing/sysfs-class-leds-virtualcolor | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-leds-virtualcolor

new file mode 100644
index 000000000000..f9b455ca34c8
@@ -0,0 +1,89 @@
+What:		/sys/class/leds/<led>/brightness
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Controls the overall brightness of the virtual LED. Setting to 0
+		deactivates the virtual LED and restores the next highest-priority
+		active LED. Setting to 1-255 activates the virtual LED and applies
+		brightness to all grouped LEDs (monochromatic and RGB).
+
+		Only the highest-priority active virtual LED is displayed at any
+		given time.
+
+		Range: 0-255 (or configured max-brightness)
+
+What:		/sys/class/leds/<led>/priority
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Sets the priority level for this virtual LED. Higher priority
+		values take precedence when multiple LEDs are active simultaneously.
+
+		When a higher-priority LED is activated:
+		- The current active LED (if lower priority) is turned off
+		- The higher-priority LED's state is applied
+		- When the higher-priority LED is deactivated, the previous LED
+		  is restored
+
+		Default: 0
+		Range: signed integer
+
+What:		/sys/class/leds/<led>/red_brightness
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Sets brightness of all red PWM LEDs in the virtual group. Only
+		affects LEDs configured under "pwm-leds-red" in device tree.
+
+		Range: 0-255
+
+What:		/sys/class/leds/<led>/green_brightness
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Sets brightness of all green PWM LEDs in the virtual group. Only
+		affects LEDs configured under "pwm-leds-green" in device tree.
+
+		Range: 0-255
+
+What:		/sys/class/leds/<led>/blue_brightness
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Sets brightness of all blue PWM LEDs in the virtual group. Only
+		affects LEDs configured under "pwm-leds-blue" in device tree.
+
+		Range: 0-255
+
+What:		/sys/class/leds/<led>/monochromatic_count
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Read-only. Shows the number of monochromatic LEDs in this virtual
+		LED group, as configured in device tree under the "leds" property.
+
+What:		/sys/class/leds/<led>/monochromatic_leds
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Read-only. Shows a comma-separated list of monochromatic LED device
+		names that are part of this virtual group. Returns "none" if no
+		monochromatic LEDs are configured.
+
+What:		/sys/class/leds/<led>/monochromatic_brightness
+Date:		October 2025
+KernelVersion:	6.13
+Contact:	Radoslav Tsvetkov <[email protected]>
+Description:
+		Read-only. Shows the current brightness values of monochromatic LEDs
+		as a comma-separated list in the same order as monochromatic_leds.
+		Returns "none" if no monochromatic LEDs are configured.
+
+		Example output:

--
2.43.0

From: Jonathan Brophy <[email protected]>

Introduces a new driver that implements virtual LED groups, aggregating multiple monochromatic LEDs into virtual groups and providing priority-based control for concurrent state management.

This driver is a work in progress, I am unable to get the read-only diagnostic sysfs attributes to show under the led framework.

Author: Radoslav Tsvetkov <[email protected]>
Co Author: Jonathan Brophy <[email protected]> Copyright (C) 2024 Jonathan Brophy <[email protected]>

---
 drivers/leds/rgb/Kconfig                   |  17 +
 drivers/leds/rgb/Makefile                  |   1 +
 drivers/leds/rgb/leds-group-virtualcolor.c | 513 +++++++++++++++++++++
 3 files changed, 531 insertions(+)
 create mode 100644 drivers/leds/rgb/leds-group-virtualcolor.c

index 222d943d826a..70a80fd46b9c 100644
@@ -75,4 +75,21 @@ config LEDS_MT6370_RGB
 	  This driver can also be built as a module. If so, the module
 	  will be called "leds-mt6370-rgb".
 
+config LEDS_GROUP_VIRTUALCOLOR
+	tristate "Virtual LED Group Driver with Priority Control"
+	depends on OF || COMPILE_TEST
+	help
+	  This option enables support for virtual LED groups that aggregate
+	  multiple monochromatic LEDs with priority-based control. It allows
+	  managing concurrent LED activation requests by ensuring only the
+	  highest-priority LED state is active at any given time.
+
+	  Multiple LEDs can be grouped together and controlled as a single
+	  virtual LED with priority levels and blinking support. This is
+	  useful for systems that need to manage multiple LED indicators
+	  with different priority levels.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called leds-group-virtualcolor.
+
 endif # LEDS_CLASS_MULTICOLOR

index a501fd27f179..693fd300b849 100644
@@ -6,3 +6,4 @@ obj-$(CONFIG_LEDS_NCP5623)		+= leds-ncp5623.o
 obj-$(CONFIG_LEDS_PWM_MULTICOLOR)	+= leds-pwm-multicolor.o
 obj-$(CONFIG_LEDS_QCOM_LPG)		+= leds-qcom-lpg.o
 obj-$(CONFIG_LEDS_MT6370_RGB)		+= leds-mt6370-rgb.o
+obj-$(CONFIG_LEDS_GROUP_VIRTUALCOLOR)	+= leds-group-virtualcolor.o

--
2.43.0

On Mon, Oct 20, 2025 at 11:29:28AM +0800, kernel test robot wrote:
...

This should use a dedicated wrapper function like a patch that I just sent for the same issue in another driver [1] to avoid a kernel control flow integrity violation at run time with CONFIG_CFI=y.

[1]: https://lore.kernel.org/20251022-ishtp-fix-function-cast-warn-v1-1-bfb06464f8ca@kernel.org/

Cheers,
Nathan

From: Dan Carpenter <[email protected]>
Sent: Monday, October 20, 2025 8:13 PM

Thank you My compiler did not pick this up.

I have been refactoring this driver for a v4 release, but I have come up with a problem in testing with a new driver.

I have converted my driver to a complete FW node implementation, but it won't work with LEDs provided by the GPIO LEDs driver as it does not work like other LED drivers.

GPIO LEDs register using devm_led_classdev_register_ext() but thet don't create a separate device structure. so there is no symbolic links or FW structures to read with the modern FW node functions.

The FWnode-based bus search (bus_find_device()) requires a device with dev_fwnode(), which GPIO LEDs don't have
of_led_get() and devm_of_led_get() have special handling in the LED core to work around this but then I'll be mixing FW node and OF functions in my current driver approach.

Do I keep with OF format or is it ok to mix and match as it has been done in LEDS GROUP multicolor and other drivers? As it was already pointed out in a past review and was not acceptable but there Is no real way around his problem otherwise I see.

my alternative option is to patch the led core to add fwnode_led_get() to Get LED classdev by FW node?

I'm wondering on the best approach here as every option has a drawback, or review problems.

Hi Jonathan,

Aren't you trying to reinvent LED trigger mechanism?

Best regards,
Jacek Anaszewski

Hei Jacek,

Am Sun, Oct 19, 2025 at 04:24:38PM +0200 schrieb Jacek Anaszewski:

Instead of using virtual LEDs, could this be implemented as a "virtual" trigger which allows grouping (and prioritizing) multiple other triggers, and apply that to only one existing LED?

Greets
Alex

Hi Alexander

I looked at this you would have to include priority for each virtual trigger and it would get very hard to understand very quickly.
then things like per channel color for each trigger etc would just be impossible to implement.. it would need a way to map and display it logically under sysfs too.

For example the additive RGB color wheel has 3 primary colors if you have a solid and a blink for each primary and secondary color that is 8 triggers for a single led.

I'm basically following the similar structure of leds-group-multicolor where they in effect create a new structure representing individual led elements but, instead of displaying the properties of the parent items, I'm creating new virtual properties that of the group in the form of a single virtual LED or a multi LED.

Userspace "driver" or rather a service would be for sure an approach quicker to implement, that would not need lengthy discussion here to achieve a consensus on the design.

Otherwise, I would see this solution rather as a new LED trigger, that would allow to define the LEDs to be grouped under it. The trigger interface would need also to allow defining patterns according to which the LEDs would be lit.

Still, the trigger would be a task for months, and would need much analysis to come up with a reasonable user interface.

Best regards,
Jacek Anaszewski

Hi Jacek

<[email protected]>; lee Jones <[email protected]>; Pavel Machek <[email protected]>; Rob Herring <[email protected]>; Krzysztof Kozlowski <[email protected]>; Conor Dooley <[email protected]>; Radoslav Tsvetkov

[email protected]

quicker to implement, that would not need lengthy discussion here to achieve a consensus on the design.

would allow to define the LEDs to be grouped under it. The trigger interface would need also to allow defining patterns according to which the LEDs would be lit.

to come up with a reasonable user interface.

The initial reason for this driver was to define aliases to point to standard triggers in OpenWrt I'm happy that this driver will fit my purpose and will solve a long-standing issue of control of status LEDs without other complicated means.

If there is a better Idea to do this awesome but I am not very skilled and I don’t know if I will be able to implement this myself.
Having these things bound in the DTS enable status LEDs to be able to connect directly to hardware triggers on things like Ethernet ports.

I also have security concerns with being able to alter triggers for important things like warning lights from userspace for the things I wish to attach them too.

What I come up with is secure and easy to work out what is going on and does not alter major parts of the framework.

With drivers everyone creates their own driver to effectively manage LED in their device, and it becomes a problem where the OpenWrt community has to reverse engineer their efforts this makes it a little bit more unified if
manufactures adopt a standard approach to led control of grouped LEDs to
format color-based status indication.

My TPlink x80-5g modem router had the basis of a similar grouping function with a similar structure in the DTS from the manufacturer but it was very basic compared to what I have created.

Best regards
Jonathan Brophy