On Fri, 7 Nov 2014 22:01:38 +0000 Mark Knibbs <markk@xxxxxxxxxxx> wrote: > This patch does two things for SCM eUSCSI USB-SCSI converters: > ... > 2. Enable multi-LUN support. eUSCSI devices don't support Get Max LUN > requests, returning an error (-32). [Different targets could have different > numbers of LUNs, so it wouldn't make sense to return a particular value in > response to Get Max LUN.] > > usb_stor_scan_dwork() does this: > ... > It avoids calling usb_stor_Bulk_max_lun() if US_FL_SINGLE_LUN, but not for > US_FL_SCM_MULT_TARG. Since usb_stor_Bulk_max_lun() returns 0 in the error > case, us->max_lun was always set to 0. > ... > v2: Rebased on the usb-next branch of gregkh usb.git 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. 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. 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. Mark -- 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
