Re: [PATCH] usb: xhci: add xhci_halt() for HCE Handling

[Thinh Nguyen]

On Fri, Feb 27, 2026, Michal Pecio wrote:
> On Fri, 27 Feb 2026 11:43:45 +0200, Mathias Nyman wrote:
> > On 2/26/26 20:17, Thinh Nguyen wrote:
> > > The controller is halted if there's an error like HCE. It's odd to
> > > try to "halt" it again. Not sure how this will impact for other
> > > controllers.
> > The host is messed up at this point, and we are not recovering it.
> > I don't think there is any harm in a manual halt at this stage.
> 
> Specifically, calling xhci_halt() clears the USBCMD.Run flag and
> all USBCMD interrupt enable flags. Seems relatively harmless. Clearing
> USBCMD.Run would be the first step of resetting the HC anyway, so the
> HW should expect it to happen afetr reporting HCE.
> 
> In case of HSE the HW should clear the Run bit by itself (4.10.2.6),
> but no such requirement seems to exist for HCE (4.24.1).

Check 4.21.2. The controller should clear the Run/Stop bit for both
cases.

> 
> The call also sets XHCI_STATE_HALTED and CMD_RING_STATE_STOPPED flags,

Perhaps we update these driver flags, but we should not need to clear
the Run/Stop bit. That's not the first thing we should do.

> which helps with recovering stuck URBs. When class drivers time out
> and unlink them, the URBs are given back instantly without drama.
> 
> I just tested the HSE case where xhci_halt() is already being called
> and it worked for me. If I remove xhci_halt() then the driver tries to
> issue Stop Endpoint commands, times out and calls hc_died(). Messy.
> I suspect that the same happened with HCE before this patch.
> 

That's just the xhci driver needing to update the software states to
properly handle the teardown knowing that the xHC is halted.

BR,
Thinh