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

Alan Stern
2025-04-07T16:11:35Z

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