Re: USB2 Link USB-SCSI converter and LUNs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@xxxxxxxxx wrote:
> Hi,
> 
> I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> 
> Adding an entry to unusual_devs.h should get it to work, just needing
> USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
> to be accessed.
> 
> However in order to access multiple targets and LUNs, the USB2 Link uses
> byte 13 of the command block wrapper in a special way.
> 
> Normally CBW byte 13 has bCBWLUN in bits [3:0] with bits [7:4] reserved.
> The USB2 Link expects the target ID in bits [3:0] and LUN in bits [7:4].

Why on earth does it use such a non-standard protocol?  After all, the 
USB mass-storage specifications have been available since 1999 or 
earlier!  And they haven't exactly been kept secret during all that 
time.

> The advantage of that is, it should be possible to access multiple targets
> without needing to modify the USB mass storage driver. (It returns 0x06 to
> a Get Max LUN request since its SCSI ID is hard-coded to 7.)
> 
> Being able to access non-zero actual LUNs would of course require changes
> to the driver.
> 
> I'm just wondering, how does the usb-storage driver handle these cases:
> 
>  - (What it thinks are) LUNs are not contiguous. Suppose the user has two
>    SCSI devices in the chain, one with ID 0 the other with ID 3. Would it
>    scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it
>    give up on getting no response from LUN 1?

This is not handled by usb-storage at all; it is handled by the SCSI 
core.  My memory of what the SCSI core does is old (so a little 
unreliable) and possibly out of date, but here it is:

The handling of non-contiguous LUNs may depend on which SCSI level the 
device claims to support.  However, in many cases the LUN scan does stop 
when no response is received.

>  - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1
>    and 3.

If there's no LUN 0 then the SCSI layer will give up on the target 
entirely.

>  - When different "LUNs" are completely different devices (e.g. one a
>    CD-ROM, another a hard disk, another a tape drive).

No matter.  Each LUN can have its own individual device type.

Alan Stern



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux