how to determine protocol of USB devices

[Kenneth D. Merry]

On Mon, Jan 30, 2017 at 10:13:42 -0800, Chuck Tuffli wrote:
> I'm trying to use CAM to determine the protocol specific command to
> send to a given device (e.g. Inquiry for SCSI devices or Identify for
> SATA devices). The code works for direct attached SCSI/SATA devices,
> but I'm not sure what to do with USB attached devices and could use
> some advice.
> 
> The current code sends a XPT_GET_TRAN_SETTINGS and uses the returned
> protocol field in the ccb_trans_settings structure. But for SATA
> drives connected via USB, the protocol is SCSI. Is there a way via CAM
> to determine that the drive is actually SATA? TIA.

I had a similar issue for camcontrol when I was working on the
firmware download code.  For SATA drives behind SAS controllers, I wanted
to send the ATA DOWNLOAD MICROCODE command via SCSI passthrough instead of
relying on the SAT layer to properly translate the various WRITE BUFFER
modes.

So, look at get_device_type() in sbin/camcontrol/camcontrol.c.  First, it
gets the protocol of the device.  For ATA, it is straightforward.  For
SCSI, it checks for the existence VPD page 0x89.  That is defined in the
SAT spec, and has to be there for a compliant SAT device.  If it's there,
then we have an ATA device behind a SAT layer.

I don't know whether USB mass storage devices follow the SAT spec as far as
translation from SCSI to ATA.  If they do, you could use that method.

If they generally support the SCSI ATA PASS-THROUGH command, you could
try using that to send an ATA Identify command down.  If you get an Illegal
Opcode ASC/ASCQ back, you've got the answer.  If it is a SATA device, it
should return Identify data.

In sbin/camcontrol/fwdownload.c I also use build_ata_cmd() (from
camcontrol.c) that allows composing one function call that then composes
either an XPT_ATA_IO or XPT_SCSI_IO CCB with the appropriate registers or
CDB.  That might be helpful if USB devices do support the ATA PASS-THROUGH
command.

That code might eventually move over to libcam, but I thought it might be
good to give it a little time before locking down the API.  The underlying
components are there, though (cam_fill_ataio() and scsi_ata_pass()).

I'm curious to hear what your solution is once you figure it out.  It would
be good to know as far as generically supporting USB devices for things
like firmware downloads.  (I don't know much about USB storage.)

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG