From: Liang Haowen <nbg2974@gmail.com>
To: Lee Jones <lee@kernel.org>
Cc: linux-leds@vger.kernel.org, linux-scsi@vger.kernel.org,
sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH RFC v2 1/1] leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe enclosures
Date: Fri, 04 Sep 2026 20:45:00 +0800 [thread overview]
Message-ID: <202609042045.ReplyLee.lhw@gmail.com> (raw)
In-Reply-To: <20260903161357.GX2133376@google.com>
On Thu, 3 Sep 2026, Lee Jones wrote:
> Please review, explain or fix the Sashiko review(s).
Fixed, fixed, fixed, false positive, false positive:
- [High] empty work run writing flash: real. The work now snapshots
the dirty mask up front and returns before issuing any SCSI command
when nothing is pending.
- [Medium] name collision between enclosures: real. With the static
name the LED core would register a second enclosure's LEDs under
renamed nodes (led0_1) rather than fail, which is still the wrong
device identity. Names now include the sdev's H:C:T:L, which is
unique per enclosure.
- [Medium] colour write vs dirty bit ordering: real on weakly ordered
architectures. A per-zone spinlock now covers the colour cache and
the mask on both sides.
- [Low] blk_rq_map_kern() argument count: false positive. The current
signature is (rq, buf, len, gfp); drivers/scsi/scsi_lib.c calls it
exactly this way from scsi_execute_cmd().
- [Low] kzalloc_obj(): false positive. It is in include/linux/slab.h
since v7.0.
v3 with the three fixes follows. One question in its cover letter:
whether deferring the Kconfig/Makefile/MAINTAINERS wiring to the
agreed SCSI split is acceptable for the RFC stage.
next prev parent reply other threads:[~2026-09-04 12:58 UTC|newest]
Thread overview: 12+ 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 ` [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
2026-09-04 12:30 ` [PATCH RFC v3 0/1] " Liang Haowen
2026-09-04 12:30 ` [PATCH RFC v3 1/1] " Liang Haowen
2026-09-04 13:15 ` sashiko-bot
2026-09-10 9:32 ` Lee Jones
2026-09-04 12:45 ` Liang Haowen [this message]
2026-09-03 12:00 ` [PATCH RFC v2 0/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=202609042045.ReplyLee.lhw@gmail.com \
--to=nbg2974@gmail.com \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.