Re: Placement of ASUS Aura and platform/x86 ASUS files relocation

> If the SCSI commands are used to issue i2c/smbus requests, then you should
> also place the i2c controller driver under /drivers/i2c/busses.


Hi Armin, Denis,

Armin, agreed on drivers/leds/ for the LED side. The enclosure isn't a platform
device and the interface is the multicolor LED sysfs, so that's the right home
for it. SCSI transport stays in drivers/scsi/.

On whether the SCSI commands wrap i2c/smbus: they don't, at least not on the
ROG STRIX Arion I reversed. The ENE controller speaks a flat register protocol
over the vendor CDB (0xec 'A' 'S' <reg_hi> <reg_lo> ... <arg_count>), with
registers for mode (0x8021), per-LED colours (0x8160), apply (0x80a0) and so on.
No i2c slave addressing shows up in the vendor CDBs, no sign of tunneling, so
there's nothing for an i2c-bus driver to model. A SCSI transport helper
in drivers/scsi/ feeding an Aura LED driver in drivers/leds/ is the shape
that matches the hardware.

I've got a working prototype that picks the enclosure up via a SCSI bus notifier
and exposes the multicolor LED; haven't posted it yet. I'll split it the way
above and send it for review.

One thing worth flagging on the transport, because it dictates how the helper
gets written. scsi_execute_cmd() sizes the CDB via COMMAND_SIZE(opcode), i.e.
scsi_command_size_tbl[(opcode >> 5) & 7], which is 10 for 0xec (group 7). The
ENE CDB is 16 bytes with arg_count in cdb[13], and the execute path does
memcpy(cmnd, cmd, cmd_len), so cdb[13] is never copied and the device just
ignores the write. I end up building the block request by hand and forcing
cmd_len=16. Anyone writing a driver that sends a vendor CDB whose real length
doesn't match COMMAND_SIZE(opcode) is going to hit the same thing.

Liang Haowen