On Mon, 18 Aug 2025 14:57:42 +0200, Niklas Neronin wrote: > A Set TR Deq Context State Error occurs when the Slot state is Enabled or > the Endpoint state is Disabled, Running, or Halted. The Slot state is > already handled, leaving the Endpoint state to be addressed. > > These are all possible Endpoint state: > > - Disabled: The Endpoint is not operational and cannot process any TDs. > Release all canceled TDs in the same way as when the Slot state is > Disabled or Enabled. This should really be prevented from happening. > - Running: Reason unknown, print a detailed warning. > > - Halted: Reason unknown, print a detailed warning. Not a bad idea, but no need to duplicate those xhci_warns. There are helpers in xhci.h to convert comp codes, endpoint states and all sorts of other magic numbers to human readable string. > - Stopped: The state is correct? Something has fixed itself, so it should > be safe to reissue a new Set TR Deq command. All TDs associated with the > failed Set TR Deq command are marked as 'TD_DIRTY'. This marking ensures > that they will be eligible for subsequent Set TR Deq command. I'm skeptical if this makes sense. What would make an endpoint run with Set TR Deq pending? What would make it stop? How much confidence there is that things aren't FUBARed beyond imagination? Was it tested? ;) Set TR Dequeue code is pretty dumb and it will jump to the first TRB after the first cancelled TD (or something like that). If the endpoint may have been running when Set TR Dequeue failed, is it guaranteed that trying again won't rewind it to some already completed TD? Is it impossible that the TD we tried to skip has been given back and the endpoint and/or slot are being disabled right now?
