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 v4 0/1] leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe enclosures
Date: Tue, 15 Sep 2026 12:48:57 -0000 [thread overview]
Message-ID: <202609152112.RFCv4-0.lhw@gmail.com> (raw)
Hello,
v4, sent as its own thread this time, addressing the third sashiko
review round (the Medium naming item is a real bug, the two Low ones
are false positives again).
Changes since v3:
- LED class device names follow the devicename:color:function scheme
again. v3 embedded the sdev's H:C:T:L verbatim
(asus-arion-0:0:0:0:led0); the extra colons break the single
separator userspace parses LED names with. The colons are now
flattened to dashes (asus-arion-0-0-0-0:led0), keeping the
per-attachment uniqueness while leaving exactly one separator.
The two low-severity items are the same false positives as before:
- kzalloc_obj() exists in include/linux/slab.h since v7.0 (Kees
Cook's overflow-refactor series); this driver builds against 7.2.
- blk_rq_map_kern() takes four arguments on current kernels
(rq, buf, len, gfp); drivers/scsi/scsi_lib.c calls it exactly this
way from scsi_execute_cmd().
v4 was re-verified on hardware: per-LED colours, 100 sequential
updates, concurrent updates from four writers, and unplug under load
(zero splats, zero leaked LED nodes, clean rmmod).
Everything else is unchanged: the hardware description, the
scsi_device_handler that does not claim the sdev, the multicolor LED
interface, the protocol handling and the known caveats (manual attach
until a notifier lands; SAVE on every update writes the enclosure
flash, wear uncharacterized; NULL-parent LED registration to avoid
the sdev reference cycle).
The open question from v3 stands: the driver is deliberately not
wired into Kconfig/Makefile/MAINTAINERS yet, because the agreed
direction with the SCSI side is a split into a SCSI transport helper
and a shared ASUS Aura LED interface, and the wiring would follow
that shape. Is deferring the wiring to that split acceptable for an
RFC, or would you rather have the driver buildable in-tree from this
series already?
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>
next reply other threads:[~2026-09-15 12:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 12:48 Liang Haowen [this message]
2026-09-15 12:49 ` [PATCH RFC v4 1/1] " Liang Haowen
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=202609152112.RFCv4-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
all inboxes | Powered by JetHome®