From: Markus Probst <markus.probst@posteo.de>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH RFC 0/4] leds: extend disk trigger
Date: Tue, 01 Sep 2026 23:00:40 +0000 [thread overview]
Message-ID: <1e8279e68f2b990e6183f5906ab0924739af28b3.camel@posteo.de> (raw)
In-Reply-To: <03a91568-d1a0-4779-a465-2788f4765a42@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]
On Mon, 2026-01-26 at 10:19 -0600, Ian Pilcher wrote:
> On 1/26/26 3:00 AM, Niklas Cassel wrote:
> > But I'm not a fan of making the driver more complex.
> > If we want something more complex than what is already there, then it
> > is probably much better handled in user space, considering the amount
> > of possible configuration options.
> >
> > Basically the same argument as used in:
> > https://lore.kernel.org/linux-nvme/20220227234258.24619-1-ematsumiya@suse.de/T/#u
>
> Niklas -
>
> Can you provide some links on how this might be done in userspace?
>
> I've been maintaining my out-of-tree block device trigger for years, to
> make the LEDs on my NAS work.
>
> https://github.com/ipilcher/ledtrig-blkdev/blob/v6.9%2B/drivers/leds/trigger/ledtrig-blkdev.c
>
> I'd love to be able to replace it with something in-tree.
(I left the mailing lists except dt in Cc, so others with the same
feature requirement can find this mail on the LKML).
Hi Ian,
In the case you are interested, I ended up writing a userspace daemon:
https://codeberg.org/0xIO32/statusd .
Also published as rust crate at https://crates.io/crates/statusd .
It has a bit more functionality, but for simple disk blinking a example
config would be:
```
disks:
# Any path that is a symlink to a block device works.
# Any component in the path can be a regex, so any special regex
characters must be escaped.
- path: '/dev/disk/by-path/pci-0000:02:00\.0-nvme-1'
present:
- led: disk1
priority: 10
mode: static
brightness: 255
io:
poll_interval: 100ms
# min_active_time: 300ms
activity:
- led: disk1
priority: 20
mode: blink
delay_on: 90
delay_off: 90
# read: [] (events in here trigger only with read activity)
# write: [] (events in here trigger only with write activity)
leds:
disk1:
name: multicolor:disk-1
default:
priority: 0
mode: static
brightness: 0
```
Config path: /etc/statusd.yaml
In this config, the led brightness is 255 if the disk is present, 0
otherwise. If there is read or write activity, it will blink with a
delay of 90 ms (brightness is unset, so it gets inherited from the
lower priority, resulting in 255).
Disk and Led Hotplugging is fine, but `ledtrig-timer` should be loaded
ahead of time or it might cause an error loop (statusd.service takes
care of that).
After the goals in the README are completed, I will try to get it
packaged into the debian repositories.
Thanks
- Markus Probst
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
next prev parent reply other threads:[~2026-09-01 23:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 19:05 [PATCH RFC 0/4] leds: extend disk trigger Markus Probst
2026-01-23 19:05 ` [PATCH RFC 1/4] leds: dt-bindings: add disk trigger led pattern Markus Probst
2026-01-23 19:05 ` [PATCH RFC 2/4] leds: dt-bindings: add disk trigger for each ata port Markus Probst
2026-01-23 19:05 ` [PATCH RFC 3/4] leds: add delay_on, delay_off and invert attributes to disk trigger Markus Probst
2026-01-23 19:18 ` Markus Probst
2026-01-23 19:05 ` [PATCH RFC 4/4] leds: add disk trigger for each ata port Markus Probst
2026-01-26 6:34 ` Damien Le Moal
2026-01-24 23:21 ` [PATCH RFC 0/4] leds: extend disk trigger Pavel Machek
2026-01-25 0:19 ` Markus Probst
2026-01-26 9:00 ` Niklas Cassel
2026-01-26 16:19 ` Ian Pilcher
2026-01-26 19:03 ` Niklas Cassel
2026-09-01 23:00 ` Markus Probst [this message]
2026-01-26 22:06 ` Markus Probst
2026-01-27 9:32 ` Niklas Cassel
2026-01-27 15:34 ` Markus Probst
2026-01-28 6:34 ` Damien Le Moal
2026-01-28 15:44 ` Markus Probst
2026-01-28 21:51 ` Niklas Cassel
2026-01-29 4:41 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1e8279e68f2b990e6183f5906ab0924739af28b3.camel@posteo.de \
--to=markus.probst@posteo.de \
--cc=arequipeno@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox