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

[Liang Haowen <nbg2974@gmail.com>]

Hi Marco,

I went through your SCSI version in PR #17 against what the hardware
told us while developing this series. The class layout fits the
device well: the ENE mode register is the hardware effect offload,
and direct streaming as table write + apply-without-save matches
what the controller does.

A few things our hardware testing can add:

- ene_write() maps the caller's buffer with blk_rq_map_kern(); your
  call sites pass stack buffers (colors[12] in direct_write). That
  is the VMAP_STACK DMA issue Lee caught in my v8: the payload needs
  a DMA-safe buffer in the device struct.

- asus_aura_brightness_set_blocking() will never run on the current
  LED core: brightness_set_blocking is superseded by the fast-path
  brightness_set there, verified with a test module on 7.2. The
  callback to use is brightness_set plus deferred work.

- The firmware effect numbers from register probing here are
  1 Static, 3 Strobe, 4 the rainbow flow (all verified on device);
  2 looks like Breathing but was not confirmed. Your mapping sends
  Spectrum Cycle to 4 and Rainbow to 5: on this enclosure 4 is the
  rainbow flow, so those two need on-device confirmation, and
  mode 0 for OFF is plausible but unverified.

- If the class core serializes the ops with led_access, sysfs ops
  cannot race each other, but trigger events reach the LED core
  without that lock, so a trigger-driven brightness update can
  still interleave with an ops sequence. The device ignores a
  sequence that loses its leading MODE write; one work item owning
  the sequence, like in this series, closes that too.

The 12-byte block write to both colour tables in one go is verified
working, so your direct_write shape is fine once the buffer is
DMA-safe.

Whatever survives your rebase, the verified SCSI core in this series
is yours to reuse; happy to rebase my side onto the class once it
settles.