1 files changed, 20 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1859378 b/results/scraper/launchpad-without-comments/1859378
new file mode 100644
index 000000000..058ea66c5
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1859378
@@ -0,0 +1,20 @@
+xhci Control Transfer requiring a Status TRB before starting transfer
+
+This may not necessarily be a bug, but more of a change.
+
+A little background may need to be in order.
+
+With all USB Control transfers, there is a SETUP transfer, zero or more DATA transfers, and if successful, a STATUS transfer.  This STATUS transfer is used to indicate to the recipient that the previous transfers were successful.  For example, in a CONTROL IN transfer, the host sends a SETUP packet to the device, receives zero or more DATA packets, and then on successful transfer, the HOST sends the STATUS packet indicating to the device that all was received.
+
+If no DATA packets are received, the HOST is not to send a STATUS packet.  This could be due to a STALL or other error.
+
+With this in mind, the STATUS transfer, in this case an xHCI STATUS TRB, may not even be on the transfer ring yet.  The HOST software may be waiting for a successful transfer before it submits the STATUS transfer.
+
+However, if you look at the test at line 1701 (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c#l1701), the current code will not start the CONTROL transfer at all if it doesn't see that STATUS TRB on the ring.
+
+In my opinion, this is in error.  It is not required that a STATUS TRB be on the ring to start the CONTROL transfer.  This STATUS TRB can be placed on the ring after a successful SETUP and zero or more DATA transfers followed by a ring to the door bell.  Then after a successful transfer to this point, placing this STATUS TRB on the ring and another ring to the door bell.
+
+In my opinion, the check at line 1701 should be removed.
+
+Thank you,
+Ben
\ No newline at end of file