On Sat, 8 Nov 2014, Mark Knibbs wrote: > It seems I didn't take into account the recent patch > "SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices"[1], > which causes my patch to not work properly. I should have actually tested it > before posting. Sigh. > > [1] https://www.mail-archive.com/linux-usb@xxxxxxxxxxxxxxx/msg47868.html > > Patch [1] added this code to usb_stor_probe2(): > /* > * Like Windows, we won't store the LUN bits in CDB[1] for SCSI-2 > * devices using the Bulk-Only transport (even though this violates > * the SCSI spec). > */ > if (us->transport == usb_stor_Bulk_transport) > us_to_host(us)->no_scsi2_lun_in_cdb = 1; > > That breaks multi-LUN support for an Entrega USB-SCSI converter with an MPL > MCDISK dual-slot PCMCIA drive. Probably all SCM-based converters would be > affected similarly. Whichever LUN is specified, LUN 0 is always accessed. Have you tested these devices with a host running Windows? > I'm not familiar with low-level aspects of parallel SCSI. How is the LUN > communicated to the target? If it's only in the CDB, then all multi-LUN > devices will be broken. On the other hand, if it's also communicated in > some other way, perhaps only some multi-LUN devices are affected. The > MCDISK is the only multi-LUN SCSI device I have. I'm not familiar with the details either. It probably varies depending on what version of SCSI the device supports. However, even if the LUN is transmitted only in the CDB, it doesn't mean that this change must break all multi-LUN devices. There's no reason the USB-SCSI adapter can't take the LUN value from the CBW and stick it into the CDB. > Since with an SCM converter you're talking to an actual parallel SCSI > device, it's probably best not to violate the SCSI spec in that case. > Changing the condition to > if (us->transport == usb_stor_Bulk_transport && > !(us->fflags & US_FL_SCM_MULT_TARG)) > seems to fix it. > > In the revised patch that I'll post shortly I chose to move the code which > sets no_scsi2_lun_in_cdb to 1 into the else clause of the previous > if (us->fflags & US_FL_SCM_MULT_TARG) { ... } else { ...} > statement. If that's not thought to be the correct approach I can post > another revised patch. The approach that's most likely to work is to imitate what Windows does. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
