linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: Alan Stern <stern@rowland.harvard.edu>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: UAS-3 and the removable bit (RMB)
Date: Wed, 29 Jul 2020 22:10:40 -0400	[thread overview]
Message-ID: <74a8caf7-710c-45f1-5b9d-3661ccc50815@interlog.com> (raw)

Hi,
T10 are working on a new UAS-3 standard. It is not that ambitious
with no ability to exploit USB4 capabilities (e.g. 40 Gbps (for
a few inches)). They are setting the bar at about the USB-3
level (i.e. about 10 years old). One thing that has been discussed
recently on the T10 reflector is the RMB (removable device) bit in
the INQUIRY response of USB devices.

There is agreement of what RMB means in the case of tape systems:
it has a tape cartridge that can be removed _and_ the tape _drive_
can still respond to SCSI commands. So it can set RMB=1 .

So what about USB memory keys? Well the USB mass storage default
seems to be to set it.

                 /*
                  * Handle those devices which need us to fake
                  * their inquiry data
                  */
                 else if ((srb->cmnd[0] == INQUIRY) &&
                             (us->fflags & US_FL_FIX_INQUIRY)) {
                         unsigned char data_ptr[36] = {
                             0x00, 0x80, 0x02, 0x02,
                             0x1F, 0x00, 0x00, 0x00};

                         usb_stor_dbg(us, "Faking INQUIRY command\n");
                         fill_inquiry_response(us, data_ptr, 36);
                         srb->result = SAM_STAT_GOOD;
                 }

That is from usb_stor_control_thread() in drivers/usb/storage/usb.c .
That seems to be for the case in which the USB storage device doesn't
supply any INQUIRY response data.

Grabbing the nearest USB stick on my desk I see:

# sg_inq /dev/sg4
invalid VPD response; probably a STANDARD INQUIRY response
standard INQUIRY:
   PQual=0  Device_type=0  RMB=1  LU_CONG=0  version=0x00  [no conformance claimed]
   [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=1
   SCCS=0  ACC=1  TPGS=3  3PC=0  Protect=1  [BQue=0]
   EncServ=1  MultiP=0  [MChngr=1]  [ACKREQQ=1]  Addr16=1
   [RelAdr=0]  WBus16=1  Sync=0  [Linked=1]  [TranDis=0]  CmdQue=0
     length=36 (0x24)   Peripheral device type: disk
  Vendor identification: Lexar
  Product identification: JD FireFly
  Product revision level: 1100


There was a T10 proposal today (20-082r0) saying that if a device
server in the target (i.e. logic in the USB storage device) can't
answer a TEST UNIT READY (TUR) appropriately when the "medium" is
absent then that device should _not_ be setting the RMB bit.

If that gets approved, what are the ramifications in changing USB
mass storage, UAS(-1) and UAS-3 code be to RMB=0 for most of its
cases? A USB SD card reader might validly set RMB=1 as it
could (should) respond with NOT READY, MEDIUM NOT PRESENT to TUR
when there is no SD card in the addressed slot.

Thoughts?

Doug Gilbert


BTW A recent approved addition to SPC-6 is to allow a device (disk)
that responds to a TUR with NOT READY, "in process of becoming ready",
to place an estimate (in milliseconds) in the INFO field of how
long before it will first respond to a TUR with GOOD status.


             reply	other threads:[~2020-07-30  2:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  2:10 Douglas Gilbert [this message]
2020-07-30 14:41 ` UAS-3 and the removable bit (RMB) Alan Stern

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=74a8caf7-710c-45f1-5b9d-3661ccc50815@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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;
as well as URLs for NNTP newsgroup(s).