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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260113115252.GF1902656@google.com>
Date: Tue, 13 Jan 2026 11:52:52 +0000
From: Lee Jones <lee@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Jonathan Brophy <professorjonny98@...il.com>,
	Pavel Machek <pavel@...nel.org>,
	Andriy Shevencho <andriy.shevchenko@...ux.intel.com>,
	Jonathan Brophy <professor_jonny@...mail.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Radoslav Tsvetkov <rtsvetkov@...dotech.eu>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-leds@...r.kernel.org
Subject: Re: [PATCH v5 0/7] leds: Add virtual LED group driver with priority
 arbitration

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