From owner-freebsd-scsi Thu Aug 22 0:24:14 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6220937B400 for ; Thu, 22 Aug 2002 00:24:12 -0700 (PDT) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [133.11.205.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F1D243E42 for ; Thu, 22 Aug 2002 00:24:11 -0700 (PDT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is1.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id 971C721814A for ; Thu, 22 Aug 2002 16:24:10 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) by is1.mh.itc.u-tokyo.ac.jp (8.11.3/8.11.3) with ESMTP id g7M7OAB14605; Thu, 22 Aug 2002 16:24:10 +0900 Received: from ett.sat.t.u-tokyo.ac.jp.sat.t.u-tokyo.ac.jp (nat.keisu.t.u-tokyo.ac.jp [133.11.68.2]) by mailhosting.itc.u-tokyo.ac.jp (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AGW29602; Thu, 22 Aug 2002 16:24:09 +0900 (JST) Date: Thu, 22 Aug 2002 16:24:09 +0900 Message-ID: From: Hidetoshi Shimokawa To: Nate Lawson Cc: scsi@freebsd.org Subject: Re: CDB6/10 negotiation In-Reply-To: References: User-Agent: Wanderlust/2.9.14 (Unchained Melody) REMI/1.14.3 (Matsudai) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 8) (Honest Recruiter) (i386--freebsd) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7: #j7i14gu$jgR\S*&C3R/pJX List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At Wed, 21 Aug 2002 13:37:50 -0700 (PDT), Nate Lawson wrote: > > I am available to do the full version suggested by Ken once we agree on a > path. However, there are a lot of people re-working CAM and I don't want > to replicate work. > > Consensus is suggesting the best approach is to put USB transport checks > under CAM_NEW_TRAN_CODE in cam_xpt.c and then use them to set > device-specific behavior. This will then restrict the commands sent to > the device according to what's reported in its inquiry. At some point > when this is working, cmd6workaround can be removed and most quirks can be > removed. The quirks that remain will truly be quirks where a device > reports capabilities it doesn't really support. > > Thoughts? Another simple but ugly soluition is rewriting inquiry response and faking to be T_RBC device rather than T_DIRECT at the trasport layer. RBC doesn't have 6 bytes command so no need to worry about it. (If the device doesn't support READ_6, it shouldn't be T_DIRECT and it should be T_RBC whatever it responses ;-) At first, I introduced cmd6workaround for SBP-II/Firewire devices, but the current driver(*) doesn't exploit it anymore and rewriting inquiry response becase I found a device which hangs up on the first 6bytes command and doesn't accept any commands anymore. (*) http://people.freebsd.org/~simokawa/ BTW, thanks for fixing cmd6workaround(), do you have a plan to MFC? /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message