On Mon, 18 Aug 2025 14:57:40 +0200, Niklas Neronin wrote: > The Set TR Deq Slot Not Enabled error occurs when the Endpoint State is > disabled. In this state, the slot's Doorbell register is disabled, meaning > it cannot receive or handle Transfer Descriptors (TDs). > > Because the slot cannot receive or handle TDs, it should not have any TDs. > Consequently, all cancelled TDs are released. > (The goto 'td_cleanup' is used for other cases in later patches) If there should be no TDs then there should be no need to clean up ;) Does xhci_hcd really need to bloat itself with workarounds for hypothetical kernel bugs which are not known to exist and which should be fixed as soon as they are discovered? And suppose that somebody does indeed disable a slot without waiting for pending URBs to finish unlinking, what if he also frees those virtual endpoints that you would like to manipulate here? And maybe forgets to clear xhci->devs[x]->eps[y] to NULL? What if a different device uses the same slot ID now? (That's possibly a serious problem which perhaps requires a serious solution, btw). The only thing we know about conditions which would cause this code to execute is that they are unknown, and the only thing we can expect is something unexpected, or else we wouldn't be here in the first place. If there are concerns that slots may be disabled while commands are pending for them, I think it would make more sense to add sanity checks right where that happens: ensure that commands cannot be queued for disabled slots, and that slots cannot be disabled with commands on them. Then at least you know which function is responsible for the screwup. In fact, I'm running a local patch which checks for pending URBs when endpoints or slots are disabled. No violations logged so far.
