RE: [PATCH 1/4] leds: Add Virtual Color LED Group driver

[Jonathan Brophy]

-----Original Message-----
From: Lee Jones <lee@xxxxxxxxxx> 
Sent: Friday, 10 October 2025 4:19 AM
To: Jonathan Brophy <professorjonny98@xxxxxxxxx>
Cc: Pavel Machek <pavel@xxxxxxxxxx>; Jonathan Brophy <professor_jonny@xxxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Radoslav Tsvetkov <rtsvetkov@xxxxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-leds@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 1/4] leds: Add Virtual Color LED Group driver

On Thu, 09 Oct 2025, Jonathan Brophy wrote:

> From: Jonathan Brophy <professor_jonny@xxxxxxxxxxx>
> 
> This commit introduces a new driver that implements virtual LED groups 
> by aggregating multiple monochromatic LEDs. The driver provides 
> priority-based control to manage concurrent LED activation requests, 
> ensuring that only the highest-priority LED group's state is active at 
> any given time.
> 
> This driver is useful for systems that require coordinated control 
> over multiple LEDs, such as RGB indicators or status LEDs that reflect 
> complex system states.
> 
> Co-developed-by: Radoslav Tsvetkov <rtsvetkov@xxxxxxxxxxxx>
> Signed-off-by: Jonathan Brophy <professor_jonny@xxxxxxxxxxx>
> ---
>  drivers/leds/rgb/Kconfig                   |  17 +
>  drivers/leds/rgb/Makefile                  |   1 +
>  drivers/leds/rgb/leds-group-virtualcolor.c | 440 
> +++++++++++++++++++++
>  3 files changed, 458 insertions(+)
>  create mode 100644 drivers/leds/rgb/leds-group-virtualcolor.c
> 
> diff --git a/drivers/leds/rgb/Kconfig b/drivers/leds/rgb/Kconfig index 
> 222d943d826a..70a80fd46b9c 100644
> --- a/drivers/leds/rgb/Kconfig
> +++ b/drivers/leds/rgb/Kconfig
> @@ -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.

Grep for:

  "This driver groups several monochromatic LED devices in a single multicolor LED device."

Does this scratch your itch?  Is this something worth building on?

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

--
Lee Jones [李琼斯]

I'm not entirely sure what you mean about grep for but I can update the message more friendly, if that is what you mean?

As for is this worth something building on....  there Are possibly more features that can be added, but it serves the purpose I intended to use it for currently, I did think it may be a security issue if one could create virtual led instances form userspace but it is a potential feature.

Other features such a cycling, diming sequences, on delay and off delay or more complex logic could be configured in the DTS I guess?.

Originally the driver was intended for OpenWrt so standard triggers and aliases can be attached to virtual LEDs,  the intention was to be able to closely match functions of OEM products status LEDs that often indicate multiple states.
The intention was to eliminate userspace scripting controlling the logic, so these statuses could be realised by just simple bindings.

There is a similar basic driver function in the Qualcomm SDK based on OpenWrt but it does not feature properties such as timing and priority.

One thing is that the led dt bindings property's function and colour are quite restrictive in naming as you can't stack the functions when you are trying to describe properties of a complex led, or if you have multiple virtual LEDs of the same color, it can get confusing as it prioritises this as opposed to the node name or label.
The label property makes it easy to describe it but this format is deprecated.

EG:

function = LED_FUNCTION_STATUS;
color = < LED_COLOR_ID_YELLOW>;

label =<YELLOW_SYSTEM_FLASHING_VIRTUAL_STAUS_LED> ;

could we stack the property function in an array to make it more descriptive:

function = < LED_FUNCTION_STATUS >, < LED_FUNCTION_FLASH>, < LED_FUNCTION_VIRTUAL_STATUS> ;

One thing I did also notice the Colour Magenta is not an available option in the DT bindings which is technically correct for an RGB LED  but violet and purple is there as a close option but I don't know where he best place is to comment on this.

Jonathan Brophy