Conversation
|
The firmware was temporarily modified to make the write consolidation occur more often. The hex digit strings are raw control request contents. The lines starting with Trace logs from waking Windows from sleep, before patch: This is the SetFeature(RemoteWakeup) sent prior to suspending the bus. These are the key press and release events to trigger the wakeup. The first transmission is skipped, and consolidated with the second. This is the timeout when Windows refuses to ACK the overly-large packet. Windows does a reset and re-enumeration. This is the ClearFeature(EndpointHalt) sent by Windows. And there is a bus reset loop, because the queued oversized packet keeps getting retransmitted. After the patch: Again, the consolidated write is queued on the peripheral. This time, the ClearFeature(EndpointHalt) works correctly, as seen by the lack of reset loop below. |
When clearing an endpoint halt condition, set endpoint status to NAK instead of VALID. When Windows receives more data than expected from an interrupt endpoint, it resets the device and attempts to clear the endpoint halt condition on that endpoint. On an IN endpoint, setting the status to VALID will cause a retransmission of the offending packet, resulting in a loop of attempted recovery operations. Signed-off-by: Taylor Yu <code@argon.blue>
Re-init the endpoint buffer state on ClearFeature(EndpointHalt). Signed-off-by: Taylor Yu <code@argon.blue>
Patch the low-level firmware to set the endpoint to NAK instead of ACK when clearing an endpoint halt. Prevents a bus reset loop situation with Windows due to an unexpectedly large queued IN packet.
Also, add a handler to reset our endpoint buffer state when the low-level firmware clears an endpoint halt.