From: Liang Haowen <nbg2974@gmail.com>
To: linux-leds@vger.kernel.org
Cc: Lee Jones <lee@kernel.org>, Pavel Machek <pavel@kernel.org>,
Martin K. Petersen <mkp@kernel.org>,
linux-scsi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org,
Denis Benato <denis.benato@linux.dev>,
Armin Wolf <W_Armin@gmx.de>, Hans de Goede <hansg@kernel.org>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>
Subject: [PATCH RFC v2 0/1] leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe enclosures
Date: Thu, 03 Sep 2026 20:00:00 +0800 [thread overview]
Message-ID: <202609032000.RFCv2-0.lhw@gmail.com> (raw)
In-Reply-To: <202609012200.RFC0.lhw@gmail.com>
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@gmail.com>
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
next prev parent reply other threads:[~2026-09-03 12:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 14:26 [PATCH RFC 0/1] leds: add ASUS Aura SCSI driver for ROG NVMe enclosures Liang Haowen
2026-09-01 14:34 ` [PATCH RFC 1/1] " Liang Haowen
2026-09-01 14:52 ` sashiko-bot
2026-09-03 12:00 ` Liang Haowen [this message]
2026-09-03 12:00 ` [PATCH RFC v2 1/1] leds: asus-aura-scsi: Add ASUS Aura RGB LED " Liang Haowen
2026-09-03 12:24 ` sashiko-bot
2026-09-03 16:13 ` Lee Jones
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=202609032000.RFCv2-0.lhw@gmail.com \
--to=nbg2974@gmail.com \
--cc=W_Armin@gmx.de \
--cc=denis.benato@linux.dev \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@kernel.org \
--cc=pavel@kernel.org \
--cc=platform-driver-x86@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