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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f76b9004-46ba-4cf6-993b-004242005d07@gmail.com>
Date: Mon, 20 Oct 2025 20:57:29 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
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" <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 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