Identify device output for SATA on big endian

[tasleson]

When I run sg_inq -p 0x89 /dev/sdf for a SSD I have in a little endian system, I get the following (SN redacted):

# sg_inq -p 0x89 /dev/sdf
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
  ATA command IDENTIFY DEVICE response summary:
    model: Samsung SSD 850 EVO 1TB                 
    serial number:     
    firmware revision: EMT01B6Q
  response in hex:
 00     0040 3fff c837 0010 0000 0000 003f 0000     .@ ?. .7 .. .. .. .? .. 
 08     0000 0000 2020 2020 2020 2020 2020 2020     .. .. 
 10     2020 2020 2020 2020 0000 0000 0000 454d                 .. .. .. EM 
 18     5430 3142 3651 5361 6d73 756e 6720 5353     T0 1B 6Q Sa ms un g  SS 
 20     4420 3835 3020 4556 4f20 3154 4220 2020     D  85 0  EV O  1T B     
 28     2020 2020 2020 2020 2020 2020 2020 8001                          .. 
 30     4001 2f00 4000 0200 0200 0007 3fff 0010     @. /. @. .. .. .. ?. .. 
 38     003f fc10 00fb 0101 ffff 0fff 0000 0007     .? .. .. .. .. .. .. .. 
 40     0003 0078 0078 0078 0078 0f10 0000 0000     .. .x .x .x .x .. .. .. 
 48     0000 0000 0000 001f 850e 00c4 016c 0060     .. .. .. .. .. .. .l .` 
 50     03fc 0039 746b 7d01 4163 7469 bc01 4163     .. .9 tk }. Ac ti .. Ac 
 58     407f 0001 0004 0000 fffe 0000 0000 0000     @. .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 6db0 7470 0000 0000     .. .. .. .. m. tp .. .. 
 68     0000 0008 4000 0000 5002 5388 700a daad     .. .. @. .. P. S. p. .. 
 70     0000 0000 0000 0000 0000 0000 0000 401e     .. .. .. .. .. .. .. @. 
 78     401c 0000 0000 0000 0000 0000 0000 0000     @. .. .. .. .. .. .. .. 
 80     0021 0000 0000 0000 0000 0000 0000 0000     .! .. .. .. .. .. .. .. 
 88     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0001 2020 2020 2020 2020 0000 0000     .. ..             .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 003d 0000     .. .. .. .. .. .. .= .. 
 d0     0000 4000 0000 0000 0000 0000 0000 0000     .. @. .. .. .. .. .. .. 
 d8     0000 0001 0000 0000 0000 0000 107f 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0800 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 4000 0000 0000 0000 0000     .. .. .. @. .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 87a5     .. .. .. .. .. .. .. ..

Same device in a big endian system:

# ./sg_inq --page 0x89 /dev/sdb
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
  ATA command IDENTIFY DEVICE response summary:
    model: aSsmnu gSS D58 0VE OT1 B                
    serial number:     
    firmware revision: ME0TB1Q6
  response in hex:
 00     4000 ff3f 37c8 1000 0000 0000 3f00 0000     @. .? 7. .. .. .. ?. .. 
 08     0000 0000 2020 2020 2020 2020 2020 2020     .. .. 
 10     2020 2020 2020 2020 0000 0000 0000 4d45                 .. .. .. ME 
 18     3054 4231 5136 6153 736d 6e75 2067 5353     0T B1 Q6 aS sm nu  g SS 
 20     2044 3538 2030 5645 204f 5431 2042 2020      D 58  0 VE  O T1  B    
 28     2020 2020 2020 2020 2020 2020 2020 0180                          .. 
 30     0140 002f 0040 0002 0002 0700 ff3f 1000     .@ ./ .@ .. .. .. .? .. 
 38     3f00 10fc fb00 0101 ffff ff0f 0000 0700     ?. .. .. .. .. .. .. .. 
 40     0300 7800 7800 7800 7800 100f 0000 0000     .. x. x. x. x. .. .. .. 
 48     0000 0000 0000 1f00 0e85 c200 6c01 6000     .. .. .. .. .. .. l. `. 
 50     fc03 3900 6b74 017d 6341 6974 01bc 6341     .. 9. kt .} cA it .. cA 
 58     7f40 0100 0400 0000 feff 0000 0000 0000     .@ .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 b06d 7074 0000 0000     .. .. .. .. .m pt .. .. 
 68     0000 0800 0040 0000 0250 8853 0a70 adda     .. .. .@ .. .P .S .p .. 
 70     0000 0000 0000 0000 0000 0000 0000 1e40     .. .. .. .. .. .. .. .@ 
 78     1c40 0000 0000 0000 0000 0000 0000 0000     .@ .. .. .. .. .. .. .. 
 80     2100 0000 0000 0000 0000 0000 0000 0000     !. .. .. .. .. .. .. .. 
 88     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0100 2020 2020 2020 2020 0000 0000     .. ..             .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 3d00 0000     .. .. .. .. .. .. =. .. 
 d0     0000 0040 0000 0000 0000 0000 0000 0000     .. .@ .. .. .. .. .. .. 
 d8     0000 0100 0000 0000 0000 0000 7f10 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0008 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 0040 0000 0000 0000 0000     .. .. .. .@ .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 a589     .. .. .. .. .. .. .. ..

From looking at the ATA specification,

Unless stated or defined otherwise, in a field containing a multi-byte value (e.g., a word, DWord, or QWord), the byte containing the LSB is stored at the lowest offset and the byte containing the MSB is stored at the highest offset.

seems to fit the description as "little endian". Looking at the output, things look correct from a strings stand point on LE system for model etc., but the hex dump for "little endian" system output looks like "big endian" output, in that the LSB is in the higher address/byte location.

If I do the following on a LE hardware, I'm assuming it's dumping the bytes in the order from the request:

# sg_inq -H -p 0x89 /dev/sdf
VPD INQUIRY, page code=0x89:
 00     00 89 02 38 00 00 00 00  6c 69 6e 75 78 20 20 20    ...8....linux   
 10     6c 69 62 61 74 61 20 20  20 20 20 20 20 20 20 20    libata          
 20     33 2e 30 30 34 80 40 00  01 00 00 00 00 00 00 00    3.004.@.........
 30     01 00 00 00 00 00 00 00  ec 00 00 00 40 00 ff 3f    ............@..?
 40     37 c8 10 00 00 00 00 00  3f 00 00 00 00 00 00 00    7.......?.......
 50     20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
 60     20 20 20 20 00 00 00 00  00 00 4d 45 30 54 42 31        ......ME0TB1
 70     51 36 61 53 73 6d 6e 75  20 67 53 53 20 44 35 38    Q6aSsmnu gSS D58
 80     20 30 56 45 20 4f 54 31  20 42 20 20 20 20 20 20     0VE OT1 B      
 90     20 20 20 20 20 20 20 20  20 20 01 80 01 40 00 2f              ...@./
 a0     00 40 00 02 00 02 07 00  ff 3f 10 00 3f 00 10 fc    .@.......?..?...
 b0     fb 00 01 01 ff ff ff 0f  00 00 07 00 03 00 78 00    ..............x.
 c0     78 00 78 00 78 00 10 0f  00 00 00 00 00 00 00 00    x.x.x...........
 d0     00 00 1f 00 0e 85 c4 00  6c 01 60 00 fc 03 39 00    ........l.`...9.
 e0     6b 74 01 7d 63 41 69 74  01 bc 63 41 7f 40 01 00    kt.}cAit..cA.@..
 f0     04 00 00 00 fe ff 00 00  00 00 00 00 00 00 00 00    ................
 100    00 00 00 00 b0 6d 70 74  00 00 00 00 00 00 08 00    .....mpt........
 110    00 40 00 00 02 50 88 53  0a 70 ad da 00 00 00 00    .@...P.S.p......
 120    00 00 00 00 00 00 00 00  00 00 1e 40 1c 40 00 00    ...........@.@..
 130    00 00 00 00 00 00 00 00  00 00 00 00 21 00 00 00    ............!...
 140    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 150    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 160    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 170    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 180    00 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00    ................
 190    20 20 20 20 20 20 20 20  00 00 00 00 00 00 00 00            ........
 1a0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1b0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 1d0    00 00 00 00 00 00 00 00  3d 00 00 00 00 00 00 40    ........=......@
 1e0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 01 00    ................
 1f0    00 00 00 00 00 00 00 00  7f 10 00 00 00 00 00 00    ................
 200    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
 210    00 00 00 08 00 00 00 00  00 00 00 00 00 00 00 00    ................
 220    00 00 00 40 00 00 00 00  00 00 00 00 00 00 00 00    ...@............
 230    00 00 00 00 00 00 00 00  00 00 a5 87                ............

I'm not sure at this point what the correct answer is.

[doug-gilbert]

That is a worry, there is supposed to be some code that works out whether the host is big or little endian and represent the word data (16 bit) accordingly. Could you try hdparm, I believe you can give it sg nodes which is useful when a SATA disk is behind a SAS expander and HBA . My guess is whichever way hdparm represents it will be correct.

[tasleson]

As requested (SN redacted again, replaced with spaces) run on LE system:

# hdparm --Istdout /dev/sdf

/dev/sdf:
0040 3fff c837 0010 0000 0000 003f 0000
0000 0000 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 0000 0000 0000 454d
5430 3142 3651 5361 6d73 756e 6720 5353
4420 3835 3020 4556 4f20 3154 4220 2020
2020 2020 2020 2020 2020 2020 2020 8001
4001 2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0101 ffff 0fff 0000 0007
0003 0078 0078 0078 0078 0f10 0000 0000
0000 0000 0000 001f 850e 00c4 016c 0060
03fc 0039 746b 7d01 4163 7469 bc01 4163
407f 0001 0004 0000 fffe 0000 0000 0000
0000 0000 0000 0000 6db0 7470 0000 0000
0000 0008 4000 0000 5002 5388 700a daad
0000 0000 0000 0000 0000 0000 0000 401e
401c 0000 0000 0000 0000 0000 0000 0000
0021 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0001 2020 2020 2020 2020 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 003d 0000
0000 4000 0000 0000 0000 0000 0000 0000
0000 0001 0000 0000 0000 0000 107f 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0800 0000 0000 0000 0000
0000 0000 0000 4000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 87a5

Also run on BE system which results in the same byte ordering output. The data is slightly different as the negotiated bus speed is lower on BE system (word 77) etc.

# uname -m
ppc64
# hdparm --Istdout /dev/sdb

/dev/sdb:
0040 3fff c837 0010 0000 0000 003f 0000
0000 0000 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 0000 0000 0000 454d
5430 3142 3651 5361 6d73 756e 6720 5353
4420 3835 3020 4556 4f20 3154 4220 2020
2020 2020 2020 2020 2020 2020 2020 8001
4001 2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0101 ffff 0fff 0000 0007
0003 0078 0078 0078 0078 0f10 0000 0000
0000 0000 0000 001f 850e 00c2 016c 0060
03fc 0039 746b 7d01 4163 7469 bc01 4163
407f 0001 0004 0000 fffe 0000 0000 0000
0000 0000 0000 0000 6db0 7470 0000 0000
0000 0008 4000 0000 5002 5388 700a daad
0000 0000 0000 0000 0000 0000 0000 401e
401c 0000 0000 0000 0000 0000 0000 0000
0021 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0001 2020 2020 2020 2020 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 003d 0000
0000 4000 0000 0000 0000 0000 0000 0000
0000 0001 0000 0000 0000 0000 107f 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0800 0000 0000 0000 0000
0000 0000 0000 4000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 89a5

[doug-gilbert]

Finding a big endian (BE) machine is getting harder and harder. NetBSD has a BE RPi image which I loaded up on a sd card and it boots. Unfortunately it does not use FreeBSD's SCSI stack so I made a sg_pt_dummy.c for it. Using the hex bytes that you provided in a file called vpd_pg89.hex I did this on the RPi BE netBSD machine:

arm64# ./sg_inq --in=/tmp/vpd_pg89.hex
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
sg_is_big_endian=1
  ATA command IDENTIFY DEVICE response summary:
    model: Samsung SSD 850 EVO 1TB                 
    serial number:                     
    firmware revision: EMT01B6Q
  response in hex:
 00     0040 3fff c837 0010 0000 0000 003f 0000     .@ ?. .7 .. .. .. .? .. 
 08     0000 0000 2020 2020 2020 2020 2020 2020     .. ..                   
 10     2020 2020 2020 2020 0000 0000 0000 454d                 .. .. .. EM 
 18     5430 3142 3651 5361 6d73 756e 6720 5353     T0 1B 6Q Sa ms un g  SS 
 20     4420 3835 3020 4556 4f20 3154 4220 2020     D  85 0  EV O  1T B     
 28     2020 2020 2020 2020 2020 2020 2020 8001                          .. 
 30     4001 2f00 4000 0200 0200 0007 3fff 0010     @. /. @. .. .. .. ?. .. 
 38     003f fc10 00fb 0101 ffff 0fff 0000 0007     .? .. .. .. .. .. .. .. 
 40     0003 0078 0078 0078 0078 0f10 0000 0000     .. .x .x .x .x .. .. .. 
 48     0000 0000 0000 001f 850e 00c4 016c 0060     .. .. .. .. .. .. .l .` 
 50     03fc 0039 746b 7d01 4163 7469 bc01 4163     .. .9 tk }. Ac ti .. Ac 
 58     407f 0001 0004 0000 fffe 0000 0000 0000     @. .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 6db0 7470 0000 0000     .. .. .. .. m. tp .. .. 
 68     0000 0008 4000 0000 5002 5388 700a daad     .. .. @. .. P. S. p. .. 
 70     0000 0000 0000 0000 0000 0000 0000 401e     .. .. .. .. .. .. .. @. 
 78     401c 0000 0000 0000 0000 0000 0000 0000     @. .. .. .. .. .. .. .. 
 80     0021 0000 0000 0000 0000 0000 0000 0000     .! .. .. .. .. .. .. .. 
 88     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0001 2020 2020 2020 2020 0000 0000     .. ..             .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 003d 0000     .. .. .. .. .. .. .= .. 
 d0     0000 4000 0000 0000 0000 0000 0000 0000     .. @. .. .. .. .. .. .. 
 d8     0000 0001 0000 0000 0000 0000 107f 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0800 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 4000 0000 0000 0000 0000     .. .. .. @. .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 87a5     .. .. .. .. .. .. .. ..

That looks correct. It is the same output as I get on a LE machine (my laptop). I added some debug output which produces the line: "sg_is_big_endian=1" and on my laptop it says: "sg_is_big_endian=0". So is there something strange about your BE machine?

[tasleson]

System is a Apple G5 Powermac. Hdparm works fine for same device on it and a Intel x86_64. sg_inq does correctly detect that it's a BE system. Anything else you would like to assist in debug? Maybe take the raw buffer and write out the array of bytes to a file on BE system?

Update: I'll try doing the raw buffer dump tomorrow on both BE and LE system. They should theoretically be virtually identical right? It should be in the interpretation and presentation that would need to be different for each arch.

[doug-gilbert]

The SAT-5 revision 5, section 12.4.3.2 says about the ATA IDENTIFY DEVICE DATA field: "The data shall be returned with byte preservation (i.e., ATA byte n maps to SCSI byte n), as shown in table 221". And that table shows Byte 0 is "ATA IDENTIFY DEVICE data word 0 bits 7:0 (i.e., byte 0)" and Byte 1 is "ATA IDENTIFY DEVICE data word 0 bits 15:8 (i.e., byte 1)" and carries on like that. So I would expect the byte representation (e.g. as shown with '-H') to be the same on BE and LE machines.

The patch I added to sg_inq.c looks like this:

    if (len < 60)
        return;
    is_be = sg_is_big_endian();
pr2serr("sg_is_big_endian=%d\n", is_be);
    if ((0xec == buff[56]) || (0xa1 == buff[56])) {
        printf("  ATA command IDENTIFY %sDEVICE response summary:\n",
               ((0xa1 == buff[56]) ? "PACKET " : ""));

The addition is the line starting with pr2serr.

[doug-gilbert]

Since you are probably using Linux, then if you can load the scsi_debug driver, it simulates VPD page 89h, among others. So that might give you another BE data point.

[tasleson]

So we believe this is a kernel issue? ref. https://lore.kernel.org/linux-ide/f0d1073e-b4a0-c255-41a3-ff52f1553c0f@interlog.com/

[doug-gilbert]

Yes, but I can't test my proposed solution. Can you?

[tasleson]

@doug-gilbert I'll see what I can do.

[tasleson]

@doug-gilbert I created the following commit against the 5.10 stable branch so that I didn't need to go through a bunch of kernel config options for my ppc64 system.

$ cat 0001-libata-Correct-big-endian-in-ata_scsiop_inq_89.patch

From a40d9eb5dc663d35624195987166706f4d8cd89e Mon Sep 17 00:00:00 2001
From: Douglas Gilbert <dgilbert@interlog.com>
Date: Tue, 22 Jun 2021 10:33:56 -0500
Subject: [PATCH] libata: Correct big endian in ata_scsiop_inq_89

The returned VPD 0x89 as detailed in the specification
should be in little endian format.  Byte swap the returned
data as needed on big endian systems.

Tested-by: Tony Asleson <tasleson@redhat.com>
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
---
 drivers/ata/libata-scsi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 48b8934970f3..6c5ff14aecea 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2075,6 +2075,7 @@ static unsigned int ata_scsiop_inq_89(struct ata_scsi_args *args, u8 *rbuf)
    rbuf[56] = ATA_CMD_ID_ATA;

    memcpy(&rbuf[60], &args->id[0], 512);
+   swap_buf_le16((u16 *)(rbuf + 60), ATA_ID_WORDS);
    return 0;
 }

base-commit: 2c85ebc57b3e1817b6ce1a6b703928e113a90442
-- 
2.32.0

Without the patch I get the following:

# sg_inq -p 0x89 /dev/sda
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
  ATA command IDENTIFY DEVICE response summary:
    model: DW CDW5200SJ4-M1BV 1                    
    serial number:     W -DCWNA1Y248002
    firmware revision: 010.E210
  response in hex:
 00     7a42 ff3f 37c8 1000 0000 0000 3f00 0000     zB .? 7. .. .. .. ?. .. 
 08     0000 0000 2020 2020 5720 2d44 4357 4e41     .. ..       W  -D CW NA 
 10     3159 3234 3830 3032 0000 0040 3200 3031     1Y 24 80 02 .. .@ 2. 01 
 18     302e 4532 3130 4457 2043 4457 3532 3030     0. E2 10 DW  C DW 52 00 
 20     534a 342d 4d31 4256 2031 2020 2020 2020     SJ 4- M1 BV  1          
 28     2020 2020 2020 2020 2020 2020 2020 1080                          .. 
 30     0000 002f 0140 0000 0000 0700 ff3f 1000     .. ./ .@ .. .. .. .? .. 
 38     3f00 10fc fb00 1001 ffff ff0f 0000 0700     ?. .. .. .. .. .. .. .. 
 40     0300 7800 7800 7800 7800 0000 0000 0000     .. x. x. x. x. .. .. .. 
 48     0000 0000 0000 0000 0606 0000 4000 4000     .. .. .. .. .. .. @. @. 
 50     fe00 0000 6b70 617e 6340 6970 413c 6340     .. .. kp a~ c@ ip A< c@ 
 58     7f40 0000 0000 0000 feff 0000 fe80 0000     .@ .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 7059 1c1d 0000 0000     .. .. .. .. pY .. .. .. 
 68     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 70     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 78     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 80     0100 0000 0000 0000 0000 6316 0000 0000     .. .. .. .. .. c. .. .. 
 88     0000 0000 0000 0000 0000 0000 0400 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 3f10 0000     .. .. .. .. .. .. ?. .. 
 d0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 d8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 a5ef     .. .. .. .. .. .. .. ..

With the patch I get:

# sg_inq -p 0x89 /dev/sda
VPD INQUIRY: ATA information page
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 3.00
  Signature (Device to host FIS):
 00     34 80 40 00 01 00 00 00  00 00 00 00 01 00 00 00
 10     00 00 00 00
  ATA command IDENTIFY DEVICE response summary:
    model: WDC WD2500JS-41MVB1                     
    serial number:      WD-WCANY1420820
    firmware revision: 10.02E01
  response in hex:
 00     427a 3fff c837 0010 0000 0000 003f 0000     Bz ?. .7 .. .. .. .? .. 
 08     0000 0000 2020 2020 2057 442d 5743 414e     .. ..        W D- WC AN 
 10     5931 3432 3038 3230 0000 4000 0032 3130     Y1 42 08 20 .. @. .2 10 
 18     2e30 3245 3031 5744 4320 5744 3235 3030     .0 2E 01 WD C  WD 25 00 
 20     4a53 2d34 314d 5642 3120 2020 2020 2020     JS -4 1M VB 1           
 28     2020 2020 2020 2020 2020 2020 2020 8010                          .. 
 30     0000 2f00 4001 0000 0000 0007 3fff 0010     .. /. @. .. .. .. ?. .. 
 38     003f fc10 00fb 0110 ffff 0fff 0000 0007     .? .. .. .. .. .. .. .. 
 40     0003 0078 0078 0078 0078 0000 0000 0000     .. .x .x .x .x .. .. .. 
 48     0000 0000 0000 0000 0606 0000 0040 0040     .. .. .. .. .. .. .@ .@ 
 50     00fe 0000 706b 7e61 4063 7069 3c41 4063     .. .. pk ~a @c pi <A @c 
 58     407f 0000 0000 0000 fffe 0000 80fe 0000     @. .. .. .. .. .. .. .. 
 60     0000 0000 0000 0000 5970 1d1c 0000 0000     .. .. .. .. Yp .. .. .. 
 68     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 70     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 78     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 80     0001 0000 0000 0000 0000 1663 0000 0000     .. .. .. .. .. .c .. .. 
 88     0000 0000 0000 0000 0000 0000 0004 0000     .. .. .. .. .. .. .. .. 
 90     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 98     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 a8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 b8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 c8     0000 0000 0000 0000 0000 0000 103f 0000     .. .. .. .. .. .. .? .. 
 d0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 d8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 e8     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f0     0000 0000 0000 0000 0000 0000 0000 0000     .. .. .. .. .. .. .. .. 
 f8     0000 0000 0000 0000 0000 0000 0000 efa5     .. .. .. .. .. .. .. ..

If you're OK with my patch, please submit upstream for inclusion. Thanks for digging into this!

[tasleson]

@doug-gilbert Update?