Date: Wed, 10 Apr 2002 14:35:58 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Nick Hibma <n_hibma@van-laarhoven.org> Cc: "Eugene M. Kim" <gene@nttmcl.com>, Oliver Fromme <olli@secnetix.de>, FreeBSD Hardware Mailing List <hardware@FreeBSD.ORG>, FreeBSD Hackers Mailing List <hackers@FreeBSD.ORG> Subject: Re: USB "Memorybird" quirks Message-ID: <20020410143558.A31045@panzer.kdm.org> In-Reply-To: <20020410213414.P27956-100000@heather.van-laarhoven.org>; from n_hibma@van-laarhoven.org on Wed, Apr 10, 2002 at 09:50:33PM %2B0200 References: <20020207125449.A9620@alicia.nttmcl.com> <20020410213414.P27956-100000@heather.van-laarhoven.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 10, 2002 at 21:50:33 +0200, Nick Hibma wrote: > > The problem is that we emulate ATAPI and UFI command sets through > converting SCSI commands. These command sets both do not have 6 byte > commands. > > The solution is to have the umass driver pass a quirk back to the CAM > layer dynamically for these devices. Any takers for an implementation > that doesn't cause a large memory overhead? The solution that doesn't > require memory consuming storing of quirks would be to have the da > peripheral driver ask the SIM (umass in this case) for the quirks. The > umass driver does not know about the attachment of the da driver to the > SCSI device we have created (nor should it), so it is difficult to find > a way to push the quirk info up to the driver. I'm all ears to good > ideas. Using the transport type might be a good way to do this. The CAM_NEW_TRAN_CODE stuff includes a transport field that would basically tell us what we need to know. We'd need to get the rest of the drivers ported over to that interface, though. > A second piece of work would be to convert all the other 6 byte commands > it produces to their 10 byte equivalents, in the same way it is done in > scsi_da.c: Pass softc->minimum_cmd_size into scsi_mode_sense and > scsi_mode_select and make those functions use the 10 byte commands > where necessary. Be careful about this; scsi_mode_sense(), scsi_mode_select(), etc., are exported to userland through libcam. If we add parameters to the functions, we probably need to create a new function name with the additional parameter, and have the old function call the new one. The alternative might be to just not have the new function exported to userland. In the typical case, you're only going to have problems with 6 bytes reads and writes. A mode sense is only issued if the device claims to support tagged queueing. (To see if the DQue bit is set in mode page 0xa.) There are other commands that can get sent, though -- inquiry, test unit ready, and start/stop unit are all 6 byte commands, and there are no 10 byte SCSI equivalents. So how do you handle those now? > And then the third one would be to have a look at for example scsi_cd.c > and friends and make similar changes there. The CD driver already uses 10 byte read and write commands, since the 6 byte read/write commands are not required for CD type devices. It does use a 6 byte mode sense/mode select, but since it rolls its own (can't remember why at the moment), that can be easily modified to look at the transport type and optionally use a 10 byte command. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020410143558.A31045>