From owner-freebsd-usb@FreeBSD.ORG  Sun Dec  2 22:46:38 2007
Return-Path: <owner-freebsd-usb@FreeBSD.ORG>
Delivered-To: freebsd-usb@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 472C416A418
	for <freebsd-usb@freebsd.org>; Sun,  2 Dec 2007 22:46:38 +0000 (UTC)
	(envelope-from bkelly@vadev.org)
Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net
	[69.17.117.10])
	by mx1.freebsd.org (Postfix) with ESMTP id 2976813C459
	for <freebsd-usb@freebsd.org>; Sun,  2 Dec 2007 22:46:36 +0000 (UTC)
	(envelope-from bkelly@vadev.org)
Received: (qmail 7896 invoked from network); 2 Dec 2007 22:19:56 -0000
Received: from vadev.org (HELO [192.168.1.98]) (Desdicardo@[66.92.166.151])
	(envelope-sender <bkelly@vadev.org>)
	by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted
	SMTP for <freebsd-usb@freebsd.org>; 2 Dec 2007 22:19:56 -0000
Message-ID: <47532FAF.6090403@vadev.org>
Date: Sun, 02 Dec 2007 17:20:31 -0500
From: Ben Kelly <bkelly@vadev.org>
User-Agent: Thunderbird 1.5.0.13 (Macintosh/20070809)
MIME-Version: 1.0
To: freebsd-usb@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [patch] possible bug in umass_scsi_transform
X-BeenThere: freebsd-usb@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: FreeBSD support for USB <freebsd-usb.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-usb>,
	<mailto:freebsd-usb-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-usb>
List-Post: <mailto:freebsd-usb@freebsd.org>
List-Help: <mailto:freebsd-usb-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-usb>,
	<mailto:freebsd-usb-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Dec 2007 22:46:38 -0000

While looking at usb/95173 I noticed what appears to be a bug in 
umass_scsi_transform().  Specifically, a TEST_UNIT_READY command will 
have the FORCE_SHORT_INQUIRY quirk logic applied to it due to the switch 
statement fall-through.  Unless these two commands are equivalent in 
some way, it would seem that you would only want to apply the 
FORCE_SHORT_INQUIRY quirk to INQUIRY commands.

I'm attaching a possible fix for the problem, but I cannot test it as I 
don't have any devices requiring these quirks.

Anyway, I just thought I would mention it.  I'm not that familiar with 
the code so its certainly possible I am off base here.

Thanks.

- Ben

--- /usr/src/sys/dev/usb/umass.c        2007-12-02 18:47:00.466926284 +0000
+++ umass.c     2007-12-02 22:07:44.896977086 +0000
@@ -3297,7 +3297,7 @@
                         (*rcmd)[4] = SSS_START;
                         return 1;
                 }
-               /* fallthrough */
+               break;
         case INQUIRY:
                 /* some drives wedge when asked for full inquiry 
information. */
                 if (sc->quirks & FORCE_SHORT_INQUIRY) {
@@ -3306,12 +3306,14 @@
                         (*rcmd)[4] = SHORT_INQUIRY_LENGTH;
                         return 1;
                 }
-               /* fallthrough */
+               break;
         default:
-               *rcmd = cmd;            /* We don't need to copy it */
-               *rcmdlen = cmdlen;
+               break;
         }

+       *rcmd = cmd;            /* We don't need to copy it */
+       *rcmdlen = cmdlen;
+
         return 1;
  }
  /* RBC specific functions */