[PATCH RFC v5 0/1] leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe enclosures

[Liang Haowen <nbg2974@gmail.com>]

Hello,

v5, as its own thread, addressing the fourth sashiko round (one real
Medium, the same two Low false positives).

Changes since v4:

- led_mc_calc_color_components() now runs under the zone spinlock.
  It writes the shared subled_info array, and the LED core allows
  concurrent brightness_set callbacks for the same LED: sysfs stores
  are serialized with led_access, but trigger events call
  led_set_brightness() without it, so two concurrent setters could
  interleave their component writes and the thread winning the lock
  would cache a mix of their colours.

The two low-severity items are the same false positives as in the
previous three rounds:

- 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(). The five-argument form with the
  request_queue first parameter is from older trees.

v5 was re-verified on hardware: per-LED colours, 100 sequential
updates, concurrent same-LED updates, concurrent four-writer updates,
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 and v4 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>