On Thu, 9 Oct 2014, Mark Knibbs wrote:
> Since setting max_lun to 0 in the US_FL_SINGLE_LUN case is done elsewhere,
> how about setting max_lun to 7 for US_FL_SCM_MULT_TARG next to that? So the
> above could could become:
>
> /*
> * Determine the max LUN value for bulk-only devices, except in
> * the US_FL_SINGLE_LUN and US_FL_SCM_MULT_TARG cases where max_lun
> * is set by usb_stor_probe2().
> */
> if (us->protocol == USB_PR_BULK &&
> !(us->fflags & (US_FL_SINGLE_LUN | US_FL_SCM_MULT_TARG))) {
> mutex_lock(&us->dev_mutex);
> us->max_lun = usb_stor_Bulk_max_lun(us);
> mutex_unlock(&us->dev_mutex);
> }
>
> Then in usb_stor_probe2():
> /* fix for single-lun devices */
> if (us->fflags & US_FL_SINGLE_LUN) {
> us->max_lun = 0;
> } else if (us->fflags & US_FL_SCM_MULT_TARG) {
> /*
> * Multiple-target devices can have different numbers of
> * LUNs on different targets. Allow all to be probed.
> */
> us->max_lun = 7;
> }
>
> That would also work if us->protocol != USB_PR_BULK.
Actually it wouldn't, because now that I think back, I remember that
other transports have no way to indicate the target number. (In fact,
the Bulk-only transport doesn't have a way to do this either -- the
mechanism used by these SCM_MULT_TARG devices is an extension to the
protocol.) So it doesn't make much sense to allow SCM_MULT_TARG unless
USB_PR_BULK is used.
> > Do you know that all SCM_MULT_TARG devices use the Bulk-only transport?
>
> Good question. It seems SCM converters support bulk-only and "CBC" (CBI
> with no command completion interrupt?); there's a comment in the Windows
> driver .INF file:
> ; DriverFlags field bitmap definition
> ; ...
> ; 0x00000010 => Force CBC Protocol
> ; 0x00000020 => Force BONLY Protocol
I don't know what CBC is. In any case, the CB code in usb-storage
doesn't support multiple targets.
> An extract from lsusb -v output for a Belkin F5U015:
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk (Zip)
> iInterface 4 BONLY and CBC Interface
>
> Three entries for SCM-based converters in unusual-devs.h have USB_SC_SCSI,
> USB_PR_BULK though (as opposed to USB_SC_DEVICE, USB_PR_DEVICE): 04E6:000B,
> 04E6:000C, and 050D:0115. I don't have any of those so can't say whether
> USB_SC_SCSI/USB_PR_BULK is necessary for those quirk entries.
>
> So the answer to your question is probably yes. But it might be better to
> not rely on that.
Actually we can rely on it. The other transports don't use multiple
targets.
> In get_transport() there is:
>
> switch (us->protocol) {
> case USB_PR_CB:
> us->transport_name = "Control/Bulk";
> us->transport = usb_stor_CB_transport;
> us->transport_reset = usb_stor_CB_reset;
> us->max_lun = 7;
> break;
>
> Could a hacky way to get an SCM converter to work with multiple LUNs be to
> just change its useProtocol UNUSUAL_DEV entry to USB_PR_CB? That should
> force the kernel to use control/bulk protocol, and thus set max_lun to 7
> with no other code change.
It will not work with targets beyond 0. It may not work at all.
> By the way: is there any technical advantage to bulk-only vs control/bulk
> protocol?
Yes; it has less overhead. For one thing, control messages involve
more packets going back and forth than bulk messages do. For another,
CB does not convey status information, so the kernel has to
specifically ask for sense data after every non-data-in command.
> To digress slightly, I just built a kernel with USB_PR_CB instead of
> USB_PR_DEVICE for the SCM converter quirk. A couple of points on testing
> that:
>
> - Throughput is faster with CB than bulk-only. Using sg_rbuf to issue
> 512KB READ BUFFER commands gives 865,160 bytes/sec with bulk-only but
> 917,865 with CB; about 6% faster. Smaller transfer sizes have a much
> greater difference; CB was 100% faster for 1KB transfer size (BOT 128000,
> CB 256000) and 33% faster for 8KB transfers (BOT 511996, CB 682667). Does
> the CB protocol have less command overhead?
>
> - I had one single-LUN drive connected, but 8 block devices were created
> (one for each LUN). With the bulk-only protocol but max_lun set to 7,
> there were no bogus/phantom drives. I wonder if the SCM converters, when
> using Control/Bulk protocol, need target/LUN information in one of the
> reserved bytes of the ADSC setup packet (bytes 2, 3 or 5)...
Don't know. You'll have to ask the manufacturer.
> > > Could any other multiple-LUN-supporting devices be affected by this issue?
> >
> > Every multiple-target USB device will be affected.
>
> Right. Are there any others, other than USB-SCSI converters?
I don't know what you mean. "Target" and "LUN" are SCSI concepts; they
don't apply to anything else. Nor does the usb-storage driver.
> Non-SCM USB-SCSI converters which support multiple targets include:
> - Adaptec USBXchange and USB2Xchange. Not supported in mainline kernel,
> though someone posted a patch a few years ago.
> - Second Wave SCUSBee. Also unsupported, and figuring out how it works
> might be tricky (wading through lots of PowerPC Mac OS driver code).
> - Ratoc U2SCX and U2SCX-LVD. Not supported in Linux either as far as I
> know. (I don't have one.)
>
> Any of those would need specific support in the kernel anyway I think,
> since (as far as I know) there isn't a standard way to access multiple
> targets.
No, there isn't.
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
