Re: [PATCH v5 0/7] leds: Add virtual LED group driver with priority arbitration

[Lee Jones <lee@kernel.org>]

On Tue, 30 Dec 2025, Jonathan Brophy wrote:

> From: Jonathan Brophy <professor_jonny@hotmail.com>
> 
> This patch series introduces a new LED driver that implements virtual LED
> groups with priority-based arbitration for shared physical LEDs. The driver
> provides a multicolor LED interface while solving the problem of multiple
> subsystems needing to control the same physical LEDs.
> 
> Key features:
> - Winner-takes-all priority-based arbitration
> - Full multicolor LED ABI compliance
> - Two operating modes (multicolor and standard/fixed-color)
> - Deterministic channel ordering by LED_COLOR_ID
> - Comprehensive debugfs telemetry (when CONFIG_DEBUG_FS enabled)
> - Optimized memory footprint (~200 bytes per LED in production builds)
> 
> Use cases:
> - System status indicators with boot/error/update priority levels
> - RGB lighting with coordinated control
> - Multi-element LED arrays unified into single logical controls
> 
> The series includes:
> 1. New LED function identifier for virtual LEDs
> 2. Device tree bindings for virtual LED class
> 3. Device tree bindings for virtual LED group controller
> 4. ABI documentation for sysfs interface
> 5. Comprehensive driver documentation
> 6. fwnode_led_get() helper for firmware-agnostic LED resolution
> 7. Complete driver implementation
> 
> Changes since v3 commit
> - convert driver to pure fwnode
> - +Multicolor LED ABI compliance - standard multi_intensity/multi_index attributes
> - Winner-takes-all arbitration - deterministic control with sequence-based tie-breaking
> - Proper LED reference management - fwnode_led_get() + led_put() prevents leaks
> - 30% memory reduction - conditional debug compilation
> - Global ownership tracking - prevents conflicts between multiple controllers
> - Hierarchical locking - documented 3-tier lock order prevents deadlocks
> - Lock-free hardware I/O - concurrent vLED updates during physical LED access
> - Dual operating modes - multicolor (dynamic) and standard (fixed-color) modes
> - Pre-allocated arbitration buffers - zero allocations in hot path
> - Comprehensive power management - suspend/resume with runtime PM support
> 
> Changes since v4 commit
> - fix yaml validation errors after feedback from maintainers from LKML
> 
> Additional highlights:
> - Update batching for software PWM workloads
> - Gamma correction for perceptual brightness
> - Rate limiting for runaway updates
> - Extensive debugfs telemetry with stress testing
> - Deferred probe handling for late-probing LEDs
> - Removal race prevention with atomic flags
> 
> Future enhancements planned:
> - dynamic led creation Chardev Interface like uleds
> - ubus/ dbus wrapper for linux and openwrt (out of tree)
> - addressable rgb support WS2812B/SK6812
> - readonly leds for important kernel/ functions
> 
> Testing:
> - Tested on ARM64 platform with GPIO and PWM LEDs
> - Stress tested with 10,000 iterations
> - Validated suspend/resume cycles
> - Memory leak detection passes
> 
> Jonathan Brophy (7):
>   dt-bindings: leds: Add LED_FUNCTION_VIRTUAL_STATUS identifier
>   dt-bindings: leds: Add virtual LED class bindings
>   dt-bindings: leds: Add virtual LED group controller bindings
>   ABI: Add sysfs documentation for leds-group-virtualcolor
>   leds: Add driver documentation for leds-group-virtualcolor
>   leds: Add fwnode_led_get() for firmware-agnostic LED resolution
>   leds: Add virtual LED group driver with priority arbitration
> 
>  .../sysfs-class-led-driver-virtualcolor       |  168 +
>  .../leds/leds-class-virtualcolor.yaml         |  197 +
>  .../leds/leds-group-virtualcolor.yaml         |  170 +
>  .../leds/leds-group-virtualcolor.rst          |  641 ++++
>  drivers/leds/led-class.c                      |  136 +-
>  drivers/leds/leds.h                           |  758 +++-
>  drivers/leds/rgb/Kconfig                      |   17 +
>  drivers/leds/rgb/Makefile                     |    1 +
>  drivers/leds/rgb/leds-group-virtualcolor.c    | 3360 +++++++++++++++++

This is an unreasonable request to ask of any reviewer.  I certainly
don't have the time to go through this in any level of detail.

-- 
Lee Jones [李琼斯]