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] [day] [month] [year] [list]
Message-ID:
 <DS0PR84MB3746D50A75BCB4DB053E008E9F8EA@DS0PR84MB3746.NAMPRD84.PROD.OUTLOOK.COM>
Date: Tue, 13 Jan 2026 20:35:50 +0000
From: Jonathan Brophy <Professor_jonny@...mail.com>
To: Lee Jones <lee@...nel.org>, Jonathan Brophy <professorjonny98@...il.com>
CC: 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

>>  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 ?

Thanks Jono


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ