On 6.3.2025 16.29, liudingyuan wrote:
I compiled a new kernel based on the fix code you provided below and conducted some preliminary tests.> In the repeated unregister/register tests of the xHCI controller that previously caused issues, both the driver and USB-related functionalities are now working normally. (Moreover, this fix code, in theory, should completely resolve the issues we encountered in our USB3-USB2 device-only scenario.) Based on the logic mentioned in analysis, we currently may not have implemented a better solution to avoid disabling interrupts during the USB2 resume process. I would like to ask if we need to be concerned about the issue of interrupt loss caused by disabling interrupts in other scenarios where resume and enumeration processes or transfer operations might conflict? For example, when a user inserts a device during the USB2/USB3 port resume, or when the USB3 controller is only connected to a USB3 devices, and the USB2 port enters this resume flow due to auto-suspend? (However, it seems that the probability of these two scenarios is very low, as we have not yet been able to reproduce errors under these conditions.) This fix indeed helps us avoid the current issue, so I would like to ask if it is possible to push this modification as a patch to the mainline code? If possible, we also plan to conduct a comprehensive test of USB functionality based on this modification to further validate it. Considering that the fix cannot completely avoid all possible scenarios where interrupts might be lost due to the hardware IE (Interrupt Enable) being turned off. I would like to ask whether the hardware design is reasonable in the following case: when a hardware edge-triggered interrupt is lost due to IE being disabled, and the subsequent interrupts cannot be triggered because the software didn't clear the EHB (Event Handler Busy) bit.
I think we can avoid this situation by disabling the primary interrupter instead of all interrupts. Meaning we would clear the 'Interrupt enable (IE)' bit:1 in Interrupter Management Register (IMAN) instead of the 'Interrupter Enable' (INTE) bit:2 in USBCMD register. This way EHB and IP shouldn't be set at all, and thus not prevent future interrupts. In practice this just means calling xhci_disable_interrupter() xhci_enable_interrupter() instead of clearing and setting CMD_EIE bit. I'll write a patch for this next week Grateful if you could run the more comprehensive test before I queue it for upstream (mainline) Thanks Mathias
