Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.

[Alan Stern]

On Mon, Apr 07, 2025 at 07:49:05AM +0200, Michał Pecio wrote:
> On Sun, 6 Apr 2025 15:26:41 -0400, Alan Stern wrote:
> > I'd guess that you're seeing the result of the
> > 
> > 		usb_disable_interface(udev, intf, true);
> > 
> > call in usb_reset_and_verify_device().  This call is made following
> > the actual reset, as part of the procedure for putting everything
> > back to the way it was before the reset.
> 
> Your guess is right. I added dump_stack() to those calls.
> 
> The bug is triggered by this function calling usb_disable_interface()
> and usb_enable_interface() after usb_hcd_alloc_bandwidth().
> 
> These two issue endpoint_disable() and endpoint_reset() to the HCD and
> xhci_hcd appears to be confused about the intent of the former, because
> it clears host_ep->hcpriv, breaking all future endpoint_reset() calls.
> 
> Since 6.15, this call informs xhci_hcd that device endpoint has been
> cleared and pending URBs can be started, so this isn't working now.
> 
> 
> BTW, that's not a corner of the driver which I'm very familiar with,
> but AFAIU this disable/enable sequence is pointless for xHCI if done
> on freshly created endpoints. It would only wait for clearing TT to
> finish (there should be none) and issue some commands to clear the
> toggle/sequence state (which should be blank).

It looks like the purpose of the calls to usb_disable_interface() and 
usb_enable_interface() in usb_reset_device() is to update the data 
structures in the core and to notify HC drivers that ignore the 
reset_device callback.

The fact is, there are lots of operations carried out by the core which 
can affect the HC drivers, and I don't think anybody has audited the 
callbacks used to communicate between the two.  I don't even know offhand 
if any HC drivers besides xhci-hcd uses these callbacks.

It would be a good idea to check whether this stuff should be updated and 
improved.

Alan Stern