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 +++++++++++++++++
 include/dt-bindings/leds/common.h             |    3 +
 10 files changed, 5399 insertions(+), 52 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-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 Documentation/leds/leds-group-virtualcolor.rst
 create mode 100644 drivers/leds/rgb/leds-group-virtualcolor.c

--
2.43.0

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 [李琼斯]

On Tue, Dec 30, 2025 at 09:23:13PM +1300, 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

I still don't really understand what you are trying to do. You need to 
tell a story not just some bullet lists. What is it you want to do that 
you can't currently support. I would start from the top level. What do 
you need to be able to do from userspace. Describe what you need to do 
not in terms of "here's how I solved/implemented it" but what does the 
current interface lack. IOW, define the problem in a way we can provide 
alternate solutions.

I see "virtual" and that screams "doesn't belong in DT" to me. I assume 
there is some physical property of why certain LEDs are grouped 
together. Convince me that the board designer would define 
the grouping rather than the user running Linux. Multi-color LEDs are 
physically packaged together for example, so defining in DT makes sense.

If you can split this up into smaller series/features, that would help 
with your upstreaming. Otherwise, it looks like a huge pile to 
try to understand and we'll likely just move on to other series which 
are easier to review.

Rob

On Tue, 06 Jan 2026, Rob Herring wrote:

> On Tue, Dec 30, 2025 at 09:23:13PM +1300, 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
> 
> I still don't really understand what you are trying to do. You need to 
> tell a story not just some bullet lists. What is it you want to do that 
> you can't currently support. I would start from the top level. What do 
> you need to be able to do from userspace. Describe what you need to do 
> not in terms of "here's how I solved/implemented it" but what does the 
> current interface lack. IOW, define the problem in a way we can provide 
> alternate solutions.

I'm inclined to agree.

Describe the problem in detail and give proper real-world examples.

> I see "virtual" and that screams "doesn't belong in DT" to me. I assume 
> there is some physical property of why certain LEDs are grouped 
> together. Convince me that the board designer would define 
> the grouping rather than the user running Linux. Multi-color LEDs are 
> physically packaged together for example, so defining in DT makes sense.

Same.  Drop the virtual keyword here since (I think) you are actually
describing the grouping of real hardware, which isn't virtual at all.

Full disclosure, I'm dropping this set for now.

I look forward to your next submission.

-- 
Lee Jones [李琼斯]