sg_opcodes reports support [DID_ABORT]

[ismaws]

I have an embedded USB device that responds to some SCSI commands e.g. sg_inq, sg_vpd, etc. When I query the device for command support around sanitize/format, it returns support even though the log captures a DID_ABORT.

I've confirmed the device does not actually support any of these commands. Can we make the support query fail on DID_ABORT instead of "Command is supported"?

[doug-gilbert]

This is a pretty ugly corner case. The sg3_utils library has an abstraction over the various OS-es it supports. The field in question transport_err and the Linux DID_* and DRIVER_* error codes are pushed through there. The trouble is Linux has this DRIVER_SENSE "transport error" which isn't a real transport error, it means "expect sense data". So one would expect on a real transport error like DID_ABORT the pass-through would not set the returned sense_data_length to > 0. But it looks like it has, so the code checked the "sense data" (and probably the SCSI status) and concluded there was no error.

Could you try again using a proper pass-through device like /dev/sg3 :-) [It is not a good idea to go through the block layer ioctl("/dev/sdc", SG_IO) unless you can't find the pass-through device.] And please add a few more '-v' options (e.g. '-vvvvvvv'). The section in the sg3_utils code that I probably need to tweak is lib/sg_cmds_basic.c in the sg_cmds_process_resp() function under the SCSI_PT_RESULT_TRANSPORT_ERR label.

Ah, I see USB is involved. IMO the only good thing about USB is USB PD; preferably using CUI's new type-C connector that only has 6 pins out of the 24 in a USB-C connector populated: 2 grounds, 2 Vbus and CC1 and CC2. Seems to me CUI have concluded that throwing away all the low speed and high speed data lines improves things and I'm inclined to agree :-)