[PATCH RFC v2 0/1] leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe enclosures
From: Liang Haowen
Date: Thu Sep 03 2026 - 08:16:16 EST
Hello,
v2 of the LED driver for ASUS Aura RGB on ROG external NVMe
enclosures. It addresses all seven points from the review v1 received
(from the sashiko AI bot; there has been no human review on v1 yet).
Changes since v1:
- Teardown order: .detach() and the attach error path now unregister
the LED class devices first, then cancel_work_sync(), then free.
The v1 order (cancel first) left a window where a brightness write
could requeue the work after cancel_work_sync() returned, so the
work would run on freed memory.
- Request allocation: ene_write() now builds the request with
scsi_alloc_request() instead of a raw blk_mq_alloc_request().
scsi_initialize_rq() zeroes cmnd, initializes the rcu head, sense
length and retries; skipping that left those fields uninitialized.
An explicit timeout and RQF_QUIET are set, matching what
scsi_execute_cmd() does.
- Serialization of the ENE sequence: brightness_set() now only caches
the colour and marks the LED in a per-zone dirty bitmap; a single
work item per zone runs one sequence (MODE, colour slots, APPLY,
SAVE) for all pending LEDs. The v1 per-LED works could interleave
their sequences between concurrent updates. As a side effect,
multi-LED updates now batch into one APPLY/SAVE.
- Subject line: switched to the leds subsystem prefix and
capitalization.
- The attach success log message is gone.
Two of the reported items did not hold up against the kernel this
driver is built against (7.2.2):
- kzalloc_obj() is not an undefined macro; it lives in
include/linux/slab.h (since v6.17).
- blk_rq_map_kern() with four arguments is the current signature
(rq, buf, len, gfp); drivers/scsi/scsi_lib.c calls it that way from
scsi_execute_cmd().
Everything else is unchanged from v1: the hardware (ROG external NVMe
enclosures, e.g. ROG STRIX Arion, USB 0b05:1932, no HID, ENE LED
controller behind vendor SCSI commands on the disk's LUN, 4
independently addressable LEDs), the scsi_device_handler that does
not claim the sdev, the multicolor LED interface, and the
protocol handling. v2 was re-verified on hardware.
Known caveats, unchanged:
- the handler attaches manually until a notifier lands
(echo asus_aura > /sys/block/sdX/device/dh_state);
- SAVE (0xaa) is issued with every colour update, which writes the
enclosure flash each time; wear has not been characterized yet;
- the LEDs are registered with a NULL parent device, because
parenting them to the sdev creates a reference cycle that blocks
the sdev's final release on unplug.
Comments on the interface shape and on folding this into the shared
Aura work with Denis remain very welcome.
Signed-off-by: Liang Haowen <nbg2974@xxxxxxxxx>
Liang Haowen (1):
leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe enclosures
drivers/leds/leds-asus-aura-scsi.c | 332 +++++++++++++++++++++++++++++
1 file changed, 332 insertions(+)
--
2.55.0