UAS data-in sent to status synchronization comment/issue

Mark Overby MOverby at
Mon Feb 8 09:28:49 PST 2010

* From the T10 Reflector (t10 at, posted by:
* Mark Overby <MOverby at>
I disagree with your position.
If you transmit status on another pipe before receiving acknowledgement, it
is possible for the host to send an indication of completion of status before
receiving all of the data. This could lead to data corruption, system
crashes, and all sort of bad behavior.
Especially in multi-threaded, multi-processor systems.
In your USB-2 case, if the ACK does get smashed - the host will issue the
next command (or commands) they will eventually time out, and error recovery
begins. This is ok.
From: owner-t10 at [owner-t10 at] On Behalf Of John Garney
[jig at]
Sent: Tuesday, February 02, 2010 7:46 AM
To: T10 at
Subject: UAS data-in sent to status synchronization comment/issue
* From the T10 Reflector (t10 at, posted by:
* John Garney <jig at>
UAS requires that the status ERDY for SuperSpeed operation is not
issued for the status endpoint until after the last transaction  for
the Data-in pipe (for a read or bi-directional command) has been
acknowledged by the host.  This synchronization requirement requires
that USB3 device silicon indicate to the device firmware/logic the
receipt of the host ACK for the data-in pipe.
Several very popular device IP cores and commercial USB 2.0 silicon
all lack the ability to let you quickly and conveniently know that
data is really transferred to the host on an IN pipe.  You get an
interrupt when data has been loaded into the FIFO, and the core takes
care of moving to the host.
These cores are used in things like cell phones, media players, and
other devices that are multi-function devices, presenting mass storage
plus other functions to the host PC as composite devices.   Virtually
every cell phone shipped today uses one of these general purpose
cores, and offers mass storage; so this is not a trivial or low-volume
use case.
This lack of precision for data transfer has not been a problem in
practice until now (for UAS) -- so the new USB3 cores will not require
this feature, and this will force use of BOT instead of UAS.
Since the reporting of the completion events of transfer requests of
data and status endpoints to the UAS driver can occur in any order in
any case (due to xHCI interrupt reporting and OS scheduling
variations), this seems like an unnecessary requirement for the
transactions on the SuperSpeed bus.
Note that this will also be an issue for USB2 UAS operation.  The ERDY
is not present, but the device shall not respond with the STATUS_IU on
the status pipe until after the host ACK on the last data-in
transaction.  And lots of current silicon doesn't have support for
that transition.
Further, in USB2, the data-in ACK can be smashed.  If the ACK is
smashed, the device won't respond with the STATUS_IU; as there is no
normal retry on ACK smash in USB2.  This smash case can be recovered
if there is a subsequent data-in transaction (as it will be detected
by data toggle state).	However, since the next transfer (for the next
command) isn't allowed until the status IU is returned, the device
will just wait.  Presumably, the host (driver) will timeout the
command; but this could turn a successful command into an error case
with a long delay.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at
This email message is for the sole use of the intended recipient(s) and may
confidential information.  Any unauthorized review, use, disclosure or
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list