> > On Fri, 2005-11-04 at 10:30 -0800, Timothy Thelin wrote: > > And for an even more concrete example: > > The CY7C68300B cypress bridge board (has various siblings as well > > on their site that act very similar) implements SCSI spec 0 (ie it > > doesn't claim to support any scsi spec). Now usb-storage sees > > this in inquiry, and decides to export the device as a scsi2 device > > since based on the usb-storage devs' experience most usb devices > > really want scsi2 cdbs. So SCSI core thinks this is a scsi2 device > > and procedes to mangle the cdbs as they're going through. > > What happens if you prevent USB mangling the scsi_level? I think, for > the most part, we would handle 0 in about the same way as we handle 2. > However, we could gate the if around the CDB[1] mangling as > > if (scsi_level != SCSI_UNKNOWN && scsi_level <= SCSI_2) > > which should fix your problem, I think. > > James > Irconically that was one of the solutions I was investigating first. Here is the usb mailing list discussion on it: http://marc.theaimsgroup.com/?t=112672009700004&r=1&w=2 In summary, the idea of making the scsi stack "level 0 aware" was suggested and rejected because usb devs want to keep promoting the devices to level 2 for various reaons. At the end of it they suggested using SG_FLAG_LUN_INHIBIT so that the usb device could stay level 2 yet vendor specific commands could get passed through un-touched. Neither of us knew that flag didn't work anymore, and after I wasn't able to get it to work, that other conversation I posted previously occured to figure out what was going on with SG_FLAG_LUN_INHIBIT. Regards, Tim Thelin - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
