On Wed, 8 Oct 2014, Mark Knibbs wrote:
> Hi,
>
> SCM-based USB-SCSI converters work with multi-LUN devices. I tested an MPL
> MCDISK-D dual PCMCIA SCSI device in a Windows XP VM (with SCM driver
> installed). Windows detected cards in both slots and added drive letters
> for them.
>
> With Linux however, only the lower slot (LUN 0) is detected. It seems the
> us->max_lun field is zero for SCM converters.
...
> I can think of several ways to fix this, and would like some input on which
> is the best/neatest:
>
> 1. Change usb_stor_Bulk_max_lun() to return 7 in the US_FL_SCM_MULT_TARG
> case (don't issue Get Max LUN to the USB device).
>
> 2. In usb_stor_scan_dwork(), don't call usb_stor_Bulk_max_lun() in the
> US_FL_SCM_MULT_TARG case, and one of:
> (a) In usb_stor_probe2(), set us->max_lun to 7 in the
> US_FL_SCM_MULT_TARG case
> (b) In get_transport(), set us->max_lun to 7 in the USB_PR_BULK case
> (c) In get_protocol(), set us->max_lun to 7 in the USB_SC_SCSI case
Either way, usb_stor_Bulk_max_lun() shouldn't do anything for
SCM_MULT_TARG devices. Indeed, the value would be meaningless because
each target can have a different number of logical units.
Since it isn't going to do anything for those devices, you might as
well avoid calling it, which means using approach 2. But instead of a,
b, or c, just do something simple like this in usb_stor_scan_dworkd():
/* For bulk-only devices, determine the max LUN value */
if (us->protocol == USB_PR_BULK && !(us->fflags & US_FL_SINGLE_LUN)) {
if (us->fflags & US_FL_SCM_MULT_TARG) {
/*
* Multiple-target devices can have different numbers
* of LUNs on different targets. We will allow all
* of them to be probed.
*/
us->max_lun = 7;
} else {
mutex_lock(&us->dev_mutex);
us->max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(&us->dev_mutex);
}
}
Do you know that all SCM_MULT_TARG devices use the Bulk-only transport?
> I compiled a kernel with option 2+(a) and it does detect LUNs > 0; here's
> part of lsscsi output with the modified kernel:
>
> [9:0:0:0]optical HP C1113M 1.19 /dev/sdg /dev/sg7
> [9:0:3:0]disk MPL MC-DISK-D-1S[0] 3.3 /dev/sdh /dev/sg8
> [9:0:3:1]disk MPL MC-DISK-D-1S[0] 3.3 - /dev/sg9
> [9:0:3:2]disk MPL MC-DISK-D-1S[1] 3.3 - /dev/sg10
> [9:0:3:3]disk MPL MC-DISK-D-1S[1] 3.3 /dev/sdi /dev/sg11
> [9:0:3:4]disk MPL MC-DISK-D-1S[1] 3.3 /dev/sdj /dev/sg12
> [9:0:3:5]disk MPL MC-DISK-D-1S[1] 3.3 /dev/sdk /dev/sg13
> [9:0:3:6]disk MPL MC-DISK-D-1S[0] 3.3 /dev/sdl /dev/sg14
> [9:0:3:7]disk MPL MC-DISK-D-1S[0] 3.3 /dev/sdm /dev/sg15
>
> Could any other multiple-LUN-supporting devices be affected by this issue?
Every multiple-target USB device will be affected.
> Perhaps option 2+(c) might be better if so?
>
> [Also, looking at get_protocol(), should max_lun be set to 0 for the
> US_SC_RBC case?]
Explicitly setting max_lun to 0 may be useful for documentation
purposes but it isn't really necessary, because the entire structure is
initialized to 0 when it is allocated. I don't know why three of the
cases bother to do it. Maybe the specifications for those protocols
forbid multiple LUNs.
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
