[PATCH] xhci: Reset controller on xhci shutdown

[PATCH] xhci: Reset controller on xhci shutdown

[wenxiong]

From: Wen Xiong <wenxiong@linux.ibm.com>

Fixes kexec boot. Without a hard reset, some USB chips will fail to
initialize in a kexec booted kernel.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Wen Xiong <wenxiong@linux.ibm.com>
---
 drivers/usb/host/xhci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a9e47e178c28..364bd61a4bd7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -781,6 +781,9 @@ void xhci_shutdown(struct usb_hcd *hcd)
 	xhci_dbg_trace(xhci, trace_xhci_dbg_init,
 			"xhci_shutdown completed - status = %x",
 			readl(&xhci->op_regs->status));
+
+	/* TI XHCI controllers do not come back after kexec without this hack */
+	pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
 }
 EXPORT_SYMBOL_GPL(xhci_shutdown);
 
-- 
2.52.0

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Mathias Nyman]

Hi

On 10/2/26 01:25, wenxiong@linux.ibm.com wrote:
> From: Wen Xiong <wenxiong@linux.ibm.com>
> 
> Fixes kexec boot. Without a hard reset, some USB chips will fail to
> initialize in a kexec booted kernel.
> 
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Wen Xiong <wenxiong@linux.ibm.com>
> ---
>   drivers/usb/host/xhci.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index a9e47e178c28..364bd61a4bd7 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -781,6 +781,9 @@ void xhci_shutdown(struct usb_hcd *hcd)
>   	xhci_dbg_trace(xhci, trace_xhci_dbg_init,
>   			"xhci_shutdown completed - status = %x",
>   			readl(&xhci->op_regs->status));
> +
> +	/* TI XHCI controllers do not come back after kexec without this hack */
> +	pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
>   }
>   EXPORT_SYMBOL_GPL(xhci_shutdown);
>   

Should be added to xhci-pci.c: xhci_pci_shutdown() instead.

Probably also limited to that specific TI xHC controller

Thanks
Mathias

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Wen Xiong]

> Should be added to xhci-pci.c: xhci_pci_shutdown() instead.
> 
> Probably also limited to that specific TI xHC controller
> 
Hi Mathias,

I will try that.

Thanks,
Wendy

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Michal Pecio]

On Thu,  1 Oct 2026 18:25:27 -0400, wenxiong@linux.ibm.com wrote:
> From: Wen Xiong <wenxiong@linux.ibm.com>
> 
> Fixes kexec boot. Without a hard reset, some USB chips will fail to
> initialize in a kexec booted kernel.

What exactly happens after kexec?
Why a PCI reset in particular?
Are we sure it's not a bug elsewhere?

Regards,
Michal

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Wen Xiong]

On 2026-10-02 03:29, Michal Pecio wrote:
> What exactly happens after kexec?
> Why a PCI reset in particular?
> Are we sure it's not a bug elsewhere?
> 
After executing a kexec boots on a bare metal machine, the USB 
controller disappeared.
With a PCI reset, the USB controller is showed up after a kexec kernel.

Thanks,
Wendy

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Michal Pecio]

On Fri, 02 Oct 2026 09:05:36 -0500, Wen Xiong wrote:
> On 2026-10-02 03:29, Michal Pecio wrote:
> > What exactly happens after kexec?
> > Why a PCI reset in particular?
> > Are we sure it's not a bug elsewhere?
> >   
> After executing a kexec boots on a bare metal machine, the USB 
> controller disappeared.

Sure, but what does it mean exactly?
Not even showing up in lspci output?

Is this our problem and not PCI subsystem's?
Are we sure it's not a bug elsewhere?

(Last time somebody reported issues with kexec,
it turned out to be an obscure Intel IOMMU bug).

Regards,
Michal

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Wen Xiong]

> Sure, but what does it mean exactly?
> Not even showing up in lspci output?

When executing "kexec -e", saw the error:
xhci_hcd 0005:01:00.0: Host halt failed. -110

USB device is still showed up in lspci but lsusb didn't show any
USB devices.
  #lspci|grep USB
0005:01:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 
3.0 xHCI Host Controller (rev 02)
[root@localhost ~]# lsusb

looks we saw a frozen USB subsystem during suspend/shutdown.

> Is this our problem and not PCI subsystem's?
> Are we sure it's not a bug elsewhere?
> 
> (Last time somebody reported issues with kexec,
> it turned out to be an obscure Intel IOMMU bug).

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Michal Pecio]

On Mon, 05 Oct 2026 08:01:46 -0500, Wen Xiong wrote:
> When executing "kexec -e", saw the error:
> xhci_hcd 0005:01:00.0: Host halt failed. -110

That's interesting, because we call xhci_halt() in xhci_shutdown().
So the xHC should already be halted before the new kernel boots and
then xhci_halt() should succeed immediately.

It seems unlikely that anything restarts the xHC (or is there a FW
involved?), so either this TI chip reacts badly to trying to halt
it again or the first halt (befor kexec) already fails, or perhaps
something is broken outside xhci_hcd.

Are you able to capture the original kernel's dmesg (through serial,
netconsole, etc) and see if the same "Host halt failed" is there?

And if you enable dynamic debug before kexec,

  echo 'module xhci_hcd +p' >/proc/dynamic_debug/control

what's printed by the debug message at the end of xhci_shutdown()?

Do you also get errors from quirk_usb_handoff_xhci() by any chance?

Regards,
Michal

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Wen Xiong]

On 2026-10-06 05:55, Michal Pecio wrote:
> Are you able to capture the original kernel's dmesg (through serial,
> netconsole, etc) and see if the same "Host halt failed" is there?
> 
Below is xhci messages after executing a kexec kernel. This is dmesg for 
kexec kernel.
[root@ltc-boston11 ~]# dmesg|grep xhci
[    1.085853] xhci_hcd 0005:01:00.0: xHCI Host Controller
[    1.085992] xhci_hcd 0005:01:00.0: new USB bus registered, assigned 
bus number 1
[    1.144472] xhci_hcd 0005:01:00.0: Host halt failed, -110
[    1.144518] xhci_hcd 0005:01:00.0: can't setup: -110
[    1.144571] xhci_hcd 0005:01:00.0: USB bus 1 deregistered
[    1.144778] xhci_hcd 0005:01:00.0: init 0005:01:00.0 fail, -110
[    1.144842] xhci_hcd 0005:01:00.0: probe with driver xhci_hcd failed 
with error -110

This is the reason why we can't see usb devices after a kexec kernel.

With the patch,
  #dmesg|grep xhci
[    0.859562] xhci_hcd 0005:01:00.0: xHCI Host Controller
[    0.859670] xhci_hcd 0005:01:00.0: new USB bus registered, assigned 
bus number 1
[    0.859797] xhci_hcd 0005:01:00.0: iommu: 64-bit OK but direct DMA is 
limited by 0
[    0.859858] xhci_hcd 0005:01:00.0: iommu: 64-bit OK but direct DMA is 
limited by 0
[    0.859982] xhci_hcd 0005:01:00.0: hcc params 0x0270f06d hci version 
0x96 quirks 0x0000000004000000
[    0.860614] xhci_hcd 0005:01:00.0: xHCI Host Controller
[    0.860719] xhci_hcd 0005:01:00.0: new USB bus registered, assigned 
bus number 2
[    0.860770] xhci_hcd 0005:01:00.0: Host supports USB 3.0 SuperSpeed
[    0.861091] usb usb1: Manufacturer: Linux 7.3.0-rc6-usb-gbatra+ 
xhci-hcd
[    0.862130] usb usb2: Manufacturer: Linux 7.3.0-rc6-usb-gbatra+ 
xhci-hcd
[    1.127210] usb 1-3: new high-speed USB device number 2 using 
xhci_hcd
[    1.407320] usb 2-2: new SuperSpeed USB device number 2 using 
xhci_hcd
[    1.556759] usb 1-4: new high-speed USB device number 3 using 
xhci_hcd
[    1.806902] usb 1-3.1: new low-speed USB device number 4 using 
xhci_hcd

#[root@ltc-boston11 ~]# lsusb
Bus 002 Device 002: ID 18a5:0252 Verbatim, Ltd
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0451:80ff Texas Instruments, Inc.
Bus 001 Device 004: ID 0557:2419 ATEN International Co., Ltd Virtual 
mouse/keyboard device
Bus 001 Device 002: ID 0557:7000 ATEN International Co., Ltd Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub



> And if you enable dynamic debug before kexec,
> 
>   echo 'module xhci_hcd +p' >/proc/dynamic_debug/control
> 
> what's printed by the debug message at the end of xhci_shutdown()?
> 
> Do you also get errors from quirk_usb_handoff_xhci() by any chance?
> 
After executing a kexec kernel, is the control setting lost?
I didn't see much useful information in control after a kexec kernel.

Probably we can resubmit the patch with mathias's suggestion.

Thanks,
Wendy

T

Re: [PATCH] xhci: Reset controller on xhci shutdown

[Michal Pecio]

On Wed, 14 Oct 2026 15:32:22 -0500, Wen Xiong wrote:
> On 2026-10-06 05:55, Michal Pecio wrote:
> > Are you able to capture the original kernel's dmesg (through serial,
> > netconsole, etc) and see if the same "Host halt failed" is there?
> >   
> Below is xhci messages after executing a kexec kernel. This is dmesg
> for kexec kernel.

OK, but I asked if you have means of capturing the old kernel's dmesg
*before* the kexec kernel begins running, including any messages from
xhci_shutdown() which may possibly be logged. This can only be done
with a serial cable, the 'netconsole' module or similar tools.

But maybe don't bother with it for now. Instead, try if this modified
version of your patch works or not:

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 34f342d2c7d7..977b2b42bcfd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -749,6 +749,7 @@ EXPORT_SYMBOL_GPL(xhci_stop);
 void xhci_shutdown(struct usb_hcd *hcd)
 {
 	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+	int err;
 
 	if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
 		usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
@@ -765,7 +766,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
 	}
 
 	spin_lock_irq(&xhci->lock);
-	xhci_halt(xhci);
+	err = xhci_halt(xhci);
 
 	/*
 	 * Workaround for spurious wakeps at shutdown with HSW, and for boot
@@ -780,6 +781,8 @@ void xhci_shutdown(struct usb_hcd *hcd)
 	xhci_dbg_trace(xhci, trace_xhci_dbg_init,
 			"xhci_shutdown completed - status = %x",
 			readl(&xhci->op_regs->status));
+	if (err)
+		pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
 }
 EXPORT_SYMBOL_GPL(xhci_shutdown);
 
---

> [root@ltc-boston11 ~]# dmesg|grep xhci
> [    1.085853] xhci_hcd 0005:01:00.0: xHCI Host Controller
> [    1.085992] xhci_hcd 0005:01:00.0: new USB bus registered, assigned 
> bus number 1
> [    1.144472] xhci_hcd 0005:01:00.0: Host halt failed, -110
> [    1.144518] xhci_hcd 0005:01:00.0: can't setup: -110
> [    1.144571] xhci_hcd 0005:01:00.0: USB bus 1 deregistered
> [    1.144778] xhci_hcd 0005:01:00.0: init 0005:01:00.0 fail, -110
> [    1.144842] xhci_hcd 0005:01:00.0: probe with driver xhci_hcd failed 
> with error -110

What about 'dmesg |grep -i xhci' (and 'grep 0005:01:00.0')?

You are likely getting errors from quirk_usb_handoff_xhci() as well.
This reminds me of a similar issue reported earlier this year:

https://lore.kernel.org/linux-usb/69fa1c3f-3ea9-42cb-a49a-7da39f72806e@molgen.mpg.de/

> This is the reason why we can't see usb devices after a kexec kernel.

No doubt about it.

> > And if you enable dynamic debug before kexec,
> > 
> >   echo 'module xhci_hcd +p' >/proc/dynamic_debug/control
> > 
> > what's printed by the debug message at the end of xhci_shutdown()?
> > 
> > Do you also get errors from quirk_usb_handoff_xhci() by any chance?
> >   
> After executing a kexec kernel, is the control setting lost?
> I didn't see much useful information in control after a kexec kernel.

Yes, the kexec kernel starts with a clean dynamic debug state.

> Probably we can resubmit the patch with mathias's suggestion.

We could also try the approach in the test patch above, but doing it
properly will require a few more changes. I haven't bothered before
we know whether this helps or not.

If it doesn't help, it will look like you have something (machine FW?)
monkeying with the chip during kexec. Then we could try fixing some
known bugs in quirk_usb_handoff_xhci(). Maybe this will be enough.

Regards,
Michal