Hello,

v7, as its own thread, addressing Lee's review of v6.

Changes since v6:

- The driver moved to drivers/leds/rgb/, where the other multicolor
  LED drivers live.

- The series is submitted with git send-email this time, so the
  patch format is the standard one.

The SCSI device handler attachment is unchanged; why it is a device
handler at all, and what the in-tree split should look like, is the
open discussion in the v6 thread.

Everything else is unchanged from v6: 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 the split lands; SAVE on every update writes the
enclosure flash, wear uncharacterized; NULL-parent LED registration
to avoid the sdev reference cycle).

Liang Haowen (1):
  leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe
    enclosures

-- 
2.55.0

On Wed, 23 Sep 2026, Liang Haowen wrote:

> Hello,
> 
> v7, as its own thread, addressing Lee's review of v6.

No, you didn't address Lee's comments but only a small part of them. :-(

Please slow down so you've time to address all feedback properly and 
double check before the next submission you've addressed all feedback 
you've received, not just part of it.

In case you think there's a comment where the reviewer is wrong, do not 
just silently ignore reviewer comments but engage by explaining why you 
think the patch is fine as is.

-- 
 i.

> Changes since v6:
> 
> - The driver moved to drivers/leds/rgb/, where the other multicolor
>   LED drivers live.
> 
> - The series is submitted with git send-email this time, so the
>   patch format is the standard one.
> 
> The SCSI device handler attachment is unchanged; why it is a device
> handler at all, and what the in-tree split should look like, is the
> open discussion in the v6 thread.
> 
> Everything else is unchanged from v6: 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 the split lands; SAVE on every update writes the
> enclosure flash, wear uncharacterized; NULL-parent LED registration
> to avoid the sdev reference cycle).
> 
> Liang Haowen (1):
>   leds: asus-aura-scsi: Add ASUS Aura RGB LED driver for ROG NVMe
>     enclosures
> 
>

On 9/23/26 12:41, Ilpo Järvinen wrote:
> On Wed, 23 Sep 2026, Liang Haowen wrote:
>
>> Hello,
>>
>> v7, as its own thread, addressing Lee's review of v6.
> No, you didn't address Lee's comments but only a small part of them. :-(
>
> Please slow down so you've time to address all feedback properly and 
> double check before the next submission you've addressed all feedback 
> you've received, not just part of it.
>
> In case you think there's a comment where the reviewer is wrong, do not 
> just silently ignore reviewer comments but engage by explaining why you 
> think the patch is fine as is.
>

Hi all,

This person is currently in asus-linux discor and he's doing what I asked him
to do: move LEDs commands from asusd (userspace) to the kernel and
for me the important part (and what I suggest review focus on) is having
a verified hardware handling code, while the led interface won't be final.

The weirdness of the driver comes from the fact that we agree on touching
the least amount possible of SCSI code since the storage part works
very well already and we simply want to bolt LEDs on top of it without
risking regressions on essential functionality.

Marco has drafted and is working on the new interface and published
a first version that I haven't got the time to review yet (university exams
period).

Anyway this interface should also be able to support what lenovo legion go
drivers currently do and when accepted it should be used by at the very least
asus, msi, lenovo but work will be long.

Liang please coordinate with Marco to use that interface (or draft a
version that can do that today). This will make like of userspace
tools developers (including other members of asus-linux) much easier.
Thanks.

Link: https://github.com/OpenGamingCollective/linux-unstable/pull/17

Best regards,
Denis Benato

Hi Denis,

Thanks for the context.

I have read Marco's Dynamic Lighting class series (PR #17). The
direct frame and palette interfaces map cleanly onto what the Arion
needs: its colour tables are just small RGB frames, and the
enclosure firmware effects map onto the class effect controls. I
will coordinate with him on using it for the LED side, on top of
the verified SCSI handling this series carries.

On the open review items: the next revision will isolate the DMA
buffer into its own cacheline (a real issue on non-coherent
architectures, as the bot notes), and I will take the time to get
the full pass right instead of rushing again.

In data mercoledì 23 settembre 2026 14:59:36 Ora legale dell’Europa centrale, 
Liang Haowen ha scritto:
> Hi Denis,
> 
> Thanks for the context.
> 
> I have read Marco's Dynamic Lighting class series (PR #17). The
> direct frame and palette interfaces map cleanly onto what the Arion
> needs: its colour tables are just small RGB frames, and the
> enclosure firmware effects map onto the class effect controls. I
> will coordinate with him on using it for the LED side, on top of
> the verified SCSI handling this series carries.
> 
> On the open review items: the next revision will isolate the DMA
> buffer into its own cacheline (a real issue on non-coherent
> architectures, as the bot notes), and I will take the time to get
> the full pass right instead of rushing again.

Hi everyone,

as for now please consider the new interface as a far from done one: it has
basic functions and works good on my laptop but, that means it is tested
only on my device using kernel 7.2.y. If you have time and want to test it
out/give feedbacks they are more than welcomed (tbh I've yet to address
these given by @Dereck due to personal reasons but I promise I'll work
on them too asap).

@Liang if you look into it there is a basic version of SCSI for your device
using the new interface: if you want to look at it feel free to do so/suggest
changes: I'll probably drop it in a future rebase to make the patchset
smaller (then again I'll have to do countless threads here in lore for leds, 
hid, wmi, etc etc etc so it will take months).

Best regards,
Marco