Message-ID: <c34fb5404e7033fe719b0072ea8a87a1caa2bf80.camel@posteo.de>
Date: Wed, 28 Jan 2026 15:44:19 +0000
From: Markus Probst <markus.probst@...teo.de>
To: Damien Le Moal <dlemoal@...nel.org>, Niklas Cassel <cassel@...nel.org>
Cc: 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>, Jacek Anaszewski <jacek.anaszewski@...il.com>, John
 Garry <john.g.garry@...cle.com>, Jason Yan <yanaijie@...wei.com>, "James
 E.J. Bottomley"	 <James.Bottomley@...senpartnership.com>, "Martin K.
 Petersen"	 <martin.petersen@...cle.com>, Pavel Machek <pavel@....cz>, 
	linux-leds@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org, 
	linux-scsi@...r.kernel.org, Ian Pilcher <arequipeno@...il.com>
Subject: Re: [PATCH RFC 0/4] leds: extend disk trigger

On Wed, 2026-01-28 at 15:34 +0900, Damien Le Moal wrote:
> On 1/28/26 12:34 AM, Markus Probst wrote:
> > > Having a user space implementation for your feature would also allow
> > > an upstream kernel, without the need for any custom kernel patches.
> > Only because it can be done in userspace, doesn't mean it should be.
> 
> Yes it should. Maintaining userspace is far easier than forcing kernel changes
> onto users to get blinking LEDs. So unless you have a very strong argument for
> doing it in the kernel, userspace is probably the right approach. That will
> apply to any block device, and not just ATA devices. E.g. NAS with M.2 NVMe
> storage can work with the same.
> 
> > > There seems to be existing user space applications that handles this,
> > > I think both the daemon I linked to before, which uses /sys/block/<dev>/stat
> > > which is thus per device and not per port, and e.g. this:
> > > https://linux.die.net/man/8/ledmon
> > > https://github.com/md-raid-utilities/ledmon
> > > https://github.com/md-raid-utilities/ledmon/blob/main/src/lib/ahci.c
> > As far as I can tell, this daemon doesn't actually use the LED
> > Subsystem, but instead leds directly connected to the storage
> > controller.
> > But yes, I would be capable of coding such daemon.
> 
> Then let's try.
I will give it a try.

@Ian: I will notify you, once there is a working version.

> That will allow checking if anything is missing in the kernel
> interface to do that nicely.
There is.

I noticed for leds, that the fwnode path isn't exposed in sysfs.
"/sys/class/leds/<name>/device/firmware_node/path" exists, but points
to the parent device.

Something similar with scsi and ata exists. scsi doesn't expose the
firmware_node and there is no symlink (or other connection that I am
ware of) between scsi_* and ata_* in sysfs. This means, I cannot map a
fwnode path to a block device.

If I want to distribute a pre-defined config for such led userspace
daemon alongside the ACPI Overlay for a specific NAS model, I need an
identifier that is equal across all devices with that specific NAS
model.

This is less of an issue for leds, but given that leds could be renamed
on name collisions the issue still exists.

Thanks
- Markus Probst

> 
> > > I think my main concern is that I don't think we should bloat the kernel
> > > for a complex feature that can just as well be implemented in user space.
> > It is still unclear to me if you worry about the complexity in
> > drivers/ata/libata-* or drivers/leds/trigger/ledtrig-disk.c
> 
> It is not so much about complexity but rather the fact that controlling
> blinking LEDs in the hot IO path is not desirable. While SATA HDDs will be less
> sensible to the delays caused by the calls to the LED control functions
> compared to fast NVMe SSDs, we do also need to think about much faster SATA
> SSDs. So instead of risking performance regressions, let's try to do this in
> userspace first.
> 

Download attachment "signature.asc" of type "application/pgp-signature" (871 bytes)

Powered by blists - more mailing lists