From owner-freebsd-scsi@freebsd.org Tue Jan 31 02:41:50 2017 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90C20CC9612 for ; Tue, 31 Jan 2017 02:41:50 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B926A62 for ; Tue, 31 Jan 2017 02:41:50 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id v0V2ff2T026887 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jan 2017 21:41:41 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id v0V2ffip026886; Mon, 30 Jan 2017 21:41:41 -0500 (EST) (envelope-from ken) Date: Mon, 30 Jan 2017 21:41:41 -0500 From: "Kenneth D. Merry" To: Chuck Tuffli Cc: freebsd-scsi Subject: Re: how to determine protocol of USB devices Message-ID: <20170131024141.GA26604@mithlond.kdm.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 30 Jan 2017 21:41:41 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 02:41:50 -0000 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@FreeBSD.ORG