When there is interrupt latency, the dwc2 driver can fail to issue its "complete split" transactions during the microframes they were scheduled for. When this happens, the result from the transaction is silently lost without producing any error. The reason the complete splits need to happen on time, is the "transaction translator" on the hub discards responses from its complete split pipeline after keeping them only 1 microframe, as specified by the usb standard. So if the complete split transactions are late, there is no way to recover. An error must be returned so higher level code can deal with the lost transaction (in my case, the USB HID driver needs to re-sync with my keyboard after losing an interrupt urb). Instead, the current code silently continues by issuing a new "start split". This next split transaction may succeed, but it is not enough since the devices thinks it has already successfully sent its interrupt transaction (it has in fact succeeded in sending the transaction to the hub, buy the hub then discarded it). My hack to fix this was to change dwc2_hc_nyet_intr() so it sets qtd->error_count=3 when past_end is true. Also I should mention I am using an old kernel 5.4.13, but based on inspection of the mainline master branch, this problem still exists in current kernels. -- Frank
