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: <20260115150725.GF2842980@google.com>
Date: Thu, 15 Jan 2026 15:07:25 +0000
From: Lee Jones <lee@...nel.org>
To: Jonathan Brophy <Professor_jonny@...mail.com>
Cc: Jonathan Brophy <professorjonny98@...il.com>,
	Pavel Machek <pavel@...nel.org>,
	Andriy Shevencho <andriy.shevchenko@...ux.intel.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Radoslav Tsvetkov <rtsvetkov@...dotech.eu>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-leds@...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, 13 Jan 2026, Jonathan Brophy wrote:

> >>  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 [李琼斯]
> 
> Hi Yes it Is a big lump of code
> I will break this down into features and separate the driver in to sub 600 lines of code in a future patch.
> 
> I'm a junior coder It is easier for me to compute as a single file but yes you are correct it is daunting.
> 
> Ill finish additions and features first then send an update patch with the driver separated for ease of review in the future.
> I expect the code to split nicely into separate sections as the below layout: 
> core.c
> arbitration.c
> phys.c
> vled.c
> debugfs.c
> virtualcolor.h
> 
> Would this be a better arrangement ?

Patches should build on each other in terms of functionality, not filename.

The first patch should provide just enough functionality to be useful.

Then build it up one piece at a time.

-- 
Lee Jones [李琼斯]