xhci Control Transfer requiring a Status TRB before starting transfer
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Invalid
|
Undecided
|
Unassigned |
Bug Description
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:/
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
Removing this check will indeed require a bit of a re-write. The way the code is now, the transfer expects a SETUP packet to be first. If you remove the check I ask about above, will the next transfer show that it is the STATUS packet? If so, then the check at line 1696 will indeed catch and not allow the STATUS packet to be accepted.
A little more work might need to be done to remove this check.
It is just a request.
Thank you,
Ben