Fix format of sntasmedia "Get Log Page" passthrough CDB

[cyrozap]

Based on my own reverse engineering efforts, the current implementation is almost correct, but there are two issues:

• The Number of Dwords Lower (NUMDL) field in this command is two bytes (big-endian), not one byte.
• The final eight bytes of the CDB are the Log Page Offset as a big-endian, 64-bit qword.

The details of this command (and others) can be found in my reverse engineering repo here (see command 0xE6: "Send NVMe Admin Command"): ​https://github.com/cyrozap/usb-to-pcie-re/blob/1f735f5ec9699d95fb802f7d82bc21ad7bd1291a/ASM236x/doc/Notes.md#usb-protocol

Attached is the patch that fixes the above issues, as well as the smartctl -d sntasmedia -q noserial -x output for two different SSD enclosures:

• An Alxum ASM2362-based enclosure with a Crucial P5 Plus SSD
• An ASM2364-based Seagate FireCuda Gaming SSD

After applying the patch, I've confirmed using Wireshark that requesting more than 512 bytes works (the most I saw requested was 1024 bytes / 0x100 dwords), and the responses contain valid data and are not truncated. No command timeouts were experienced during this testing.

[Christian Franke]

Thanks! Please also include an addition to the ChangeLog file in your patch (mail address is optional).

• The final eight bytes of the CDB are the Log Page Offset as a big-endian, 64-bit qword.

Is 64-support a guess or did you actually test this with cdw13 != 0 ?
Smartctl never sets cdw13 and such large log pages may not exits in practice.

Unfortunately issuing the no-data NVMe Self-Test command (0x14) through this bridge does apparently not work.

[cyrozap]

Replying to Christian Franke:

Thanks! Please also include an addition to the ChangeLog file in your patch (mail address is optional).

Done.

• The final eight bytes of the CDB are the Log Page Offset as a big-endian, 64-bit qword.

Is 64-support a guess or did you actually test this with cdw13 != 0 ?
Smartctl never sets cdw13 and such large log pages may not exits in practice.

It's based on inspection of the bridge chip's firmware--when the firmware receives the "Get Log Page" CDB it takes the last 8 bytes, reverses their order, and stores them into CDW12 and CDW13. I'm not sure why ASMedia chose to enable the firmware to support such large Log Page Offsets, but that's what the firmware does.

Unfortunately issuing the no-data NVMe Self-Test command (0x14) through this bridge does apparently not work.

That's right, only commands 0x02 (Get Log Page) and 0x06 (Identify) are supported.

[Christian Franke]

Applied in r5568. Thanks!