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

[Marco Scardovi <scardracs@disroot.org>]

In data venerdì 25 settembre 2026 14:22:03 Ora legale dell’Europa centrale, 
Liang Haowen ha scritto:
> 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.

Hi Liang,

I've read your mail: as said on github I've dropped both scsi and tuf as
I don't own any of these: I'll leave them to you and voidvore. If you find
my pieces of code useful in any way feel free to pick them up and implement
them in your code (please don't add me as co-author as I would not be able to 
test or maintain the code in the long run): as soon as it will be stable 
enough I'll proceed to post it here in lore too.

Marco