public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: mark_k@iname.com
Cc: linux-usb@vger.kernel.org
Subject: Re: USB2 Link USB-SCSI converter and LUNs
Date: Tue, 19 Oct 2021 10:32:29 -0400	[thread overview]
Message-ID: <20211019143229.GA1082114@rowland.harvard.edu> (raw)
In-Reply-To: <trinity-d3be8a5b-2b1c-45f8-8767-cf9cf758a0c0-1634638509008@3c-app-mailcom-lxa12>

On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com 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

  parent reply	other threads:[~2021-10-19 14:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-19 10:15 USB2 Link USB-SCSI converter and LUNs mark_k
2021-10-19 11:18 ` Greg KH
2021-10-19 12:53   ` mark_k
2021-10-19 13:01     ` Greg KH
2021-10-19 16:37       ` mark_k
2021-10-19 17:25         ` Alan Stern
2021-10-19 14:32 ` Alan Stern [this message]
2021-10-19 16:49   ` mark_k

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211019143229.GA1082114@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark_k@iname.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox