linux-kernel - RE: [PATCH v3 0/4] leds: Add a virtual LED driver for groups of

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: <003e01dc420a$df26a430$9d73ec90$@gmail.com>
Date: Tue, 21 Oct 2025 10:45:32 +1300
From: <professorjonny98@...il.com>
To: "'Jacek Anaszewski'" <jacek.anaszewski@...il.com>,
	"'Jonathan Brophy'" <Professor_jonny@...mail.com>,
	"'lee Jones'" <lee@...nel.org>,
	"'Pavel Machek'" <pavel@...nel.org>,
	"'Rob Herring'" <robh@...nel.org>,
	"'Krzysztof Kozlowski'" <krzk+dt@...nel.org>,
	"'Conor Dooley'" <conor+dt@...nel.org>,
	"'Radoslav Tsvetkov'" <rtsvetkov@...dotech.eu>
Cc: <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	<linux-leds@...r.kernel.org>
Subject: RE: [PATCH v3 0/4] leds: Add a virtual LED driver for groups of

Hi Jacek

>From: Jacek Anaszewski <jacek.anaszewski@...il.com> 
>Sent: Tuesday, 21 October 2025 7:57 AM
>To: Jonathan Brophy <Professor_jonny@...mail.com>; Jonathan Brophy
<professorjonny98@...il.com>; lee Jones <lee@...nel.org>; Pavel Machek
<pavel@...nel.org>; Rob Herring <robh@...nel.org>; Krzysztof Kozlowski
<krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>; Radoslav Tsvetkov
><rtsvetkov@...dotech.eu>
>Cc: devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
linux-leds@...r.kernel.org
>Subject: Re: [PATCH v3 0/4] leds: Add a virtual LED driver for groups of
>
>On 10/19/25 23:17, Jonathan Brophy wrote:
>> on 10/20/25 3:25am Jacek Anaszewski wrote:
>>> On 10/19/25 11:23, Jonathan Brophy wrote:
>> 
>>>> From: Jonathan Brophy <professor_jonny@...mail.com>
>>>>
>>>> Introduce a new driver that implements virtual LED groups, 
>>>> aggregating multiple monochromatic LEDs into virtual groups and 
>>>> providing priority-based control for concurrent state management.
>>>
>>>Aren't you trying to reinvent LED trigger mechanism?
>>>
>>>--
>>>Best regards,
>>>Jacek Anaszewski
>> 
>> It is much simpler than that, I'm just trying to group LEDs into a new 
>> virtual (fake) leds with some priority rules and define all this in 
>> the DTS.
>> 
>> Consider below is a dts of my router as an example.
>> 
>> The leds node is the actual status LED I have in my router three 
>> elements red, green and blue:
>> 
>> Then I have my virtualcolor_leds node defining my groups that consist 
>> of these elements.
>> 
>> I have two leds defined in each color I wish to display one that 
>> blinks and one that does not.
>> 
>>  From here I can define all my led colors and logic pattern in the 
>> device tree.
>> 
>> These virtual LEDs just appear as regular LEDs in sysfs.
>> 
>> After a factory reset of my device I would expect the status led to be 
>> solid yellow when it starts up then when ready to setup blink blue 
>> ready for setup.
>> 
>> It I connected these ot standard triggers I would end up with a mess 
>> not knowing the status if multiple triggers operated at the same time.
>> 
>> Without the logic I would likely after boot have a yellow led that 
>> flashes white as the solid yellow would mix with the flashing blue by 
>> mixing of the power  and setting up triggers.
>> 
>> I can define aliases to the virtual leds for access within user space 
>> and have all the features of a normal led with out the logic headache.
>> 
>> My alternative is to create a driver defining logic in userspace with 
>> a cronjob or as such or with a custom binary.
>
>Userspace "driver" or rather a service would be for sure an approach
quicker to implement, that would not need lengthy discussion here to achieve
a consensus on the design.
>
>Otherwise, I would see this solution rather as a new LED trigger, that
would allow to define the LEDs to be grouped under it. The trigger interface
would need also to allow defining patterns according to which the LEDs would
be lit.
>
>Still, the trigger would be a task for months, and would need much analysis
to come up with a reasonable user interface.
>
>--
>Best regards,
>Jacek Anaszewski


The initial reason for this driver was to define aliases to point to
standard triggers in OpenWrt I'm happy that this driver will fit my purpose
and will solve a long-standing issue of control of status LEDs without other
complicated means.

If there is a better Idea to do this awesome but I am not very skilled and I
dont know if I will be able to implement this myself.
Having these things bound in the DTS enable status LEDs to be able to
connect directly to hardware triggers on things like Ethernet ports.

I also have security concerns with being able to alter triggers for
important things like warning lights from userspace for the things I wish to
attach them too.

What I come up with is secure and easy to work out what is going on and does
not alter major parts of the framework.

With drivers everyone creates their own driver to effectively manage LED in
their device, and it becomes a problem where the OpenWrt community has to
reverse engineer their efforts this makes it a little bit more unified if
 manufactures adopt a standard approach to led control of grouped LEDs to
format color-based status indication.

My TPlink x80-5g modem router had the basis of a similar grouping function
with a similar structure in the DTS from the manufacturer but it was very
basic compared to what I have created.

Best regards
Jonathan Brophy