UAS-3 and the removable bit (RMB)

UAS-3 and the removable bit (RMB)

[Douglas Gilbert]

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.

Re: UAS-3 and the removable bit (RMB)

[Alan Stern]

On Wed, Jul 29, 2020 at 10:10:40PM -0400, Douglas Gilbert wrote:
> 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.

This is very much _not_ the default.  The US_FL_FIX_INQUIRY flag is set 
only for the small percentage of USB mass-storage devices that can't 
handle the INQUIRY command themselves; the default is to use the data 
provided by the device.

>                 /*
>                  * 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.

Correct.

> 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

Looks like this reply was generated by the USB stick and not by the 
driver (none of the unusual*.h files in the source directory include 
the string "JD Firefly").

There's nothing really wrong with setting the RMB bit for devices that 
don't have removable media, is there?  They will simply act as though 
the medium is always present.

> 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.

I don't know of any cases where a USB mass-storage device fails to 
handle TUR correctly when the medium is absent.  This isn't to say there 
are none at all, but there can't be very many.

In any case, it seems unlikely that this change will have any impact on 
the drivers.  Perhaps some of the sub-drivers for usb-storage (files 
like jumpshot.c or sddr09.c) might need to be adjusted a little, but the 
devices that these files were meant for are becoming less and less 
common.

Furthermore, in all cases where usb-storage manufactures INQUIRY 
information for devices that can't provide it, the ANSI-approved version 
number field is set to 2, meaning that we claim to be conformant only 
with a very early version of the spec.  Changes made in newer versions 
are therefore irrelevant.  The uas driver doesn't manufacture INQUIRY 
responses at all.

> Thoughts?

In the vast majority of cases, usb-storage and uas just return the 
INQUIRY data that was sent by the device.  Surely that wouldn't need to 
change (any more than some other SCSI host adapter driver would need to 
change), even if the devices themselves are rendered non-compliant by a 
change to the spec.

Alan Stern

> 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.