On Mon, Nov 07, 2005 at 02:53:34PM -0500, Alan Stern wrote: > On Mon, 7 Nov 2005, Patrick Mansfield wrote: > > Can we trigger black listing based on the above vendor/product values? > > i.e. can you check for these values in usb-storage slave_configure code? > > Yes. The patch below illustrates how. You'll have to change the name of > the sdev flag to something sensible... > > I firmly believe this is the wrong approach, however. It's a specific > solution to a general problem. I would much prefer to add a new flag to > struct request. We have the specific problem of a device being reported as scsi-2 compliant when it is not. Stepping back a bit ... usb-storage should pass through the scsi level, we should not require special handling (adding back inhibit lun support or a new black list option) for compliant hardware. So, do we have a usb-storage problem or non-compliant hardware here? I did not find the answer in previous emails. That is, is usb-storage forcing scsi-2 when the device tells us it is scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet requiring non-LUN value in cdb[1]? A method that can reliably and easily set some black list value for the hardware in question will to lead to fewer questions in the future as to why an SG_IO command is getting LUN values set in cdb[1]. If this is a hardware problem I'm not opposed to adding back support for the ioctl and AFAIUI a new struct request flag. -- Patrick Mansfield - : 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
