[PATCH V3] xhci: Reset TI USB controller on xhci shutdown

[PATCH V3] xhci: Reset TI USB controller on xhci shutdown

[wenxiong]

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

Fixes kexec boot. Without a hard reset, TI pci usb chips will fail to
initialize in a kexec booted kernel.

Signed-off-by: Wen Xiong <wenxiong@linux.ibm.com>
---
 drivers/usb/host/xhci-pci.c | 4 +++-
 drivers/usb/host/xhci.c     | 8 ++++++++
 drivers/usb/host/xhci.h     | 1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index a8889081ae82..782178da4057 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -479,8 +479,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 	    pdev->device == PCI_DEVICE_ID_ASMEDIA_3042_XHCI)
 		xhci->quirks |= XHCI_RESET_ON_RESUME;
 
-	if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
+	if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) {
 		xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
+		xhci->quirks |= XHCI_RESET_ON_SHUTDOWN;
+	}
 
 	if ((pdev->vendor == PCI_VENDOR_ID_BROADCOM ||
 	     pdev->vendor == PCI_VENDOR_ID_CAVIUM) &&
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a9e47e178c28..8e5e25ebb6b5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -750,6 +750,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));
@@ -781,6 +782,13 @@ 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 fail to initialize in a kexec
+	 * kernel without a PCI function reset
+	 */
+	if (err && (xhci->quirks & XHCI_RESET_ON_SHUTDOWN))
+		pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
 }
 EXPORT_SYMBOL_GPL(xhci_shutdown);
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index c7bfa7f028d3..e94a38e5f4ac 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1647,6 +1647,7 @@ struct xhci_hcd {
 #define XHCI_CDNS_SCTX_QUIRK	BIT_ULL(48)
 #define XHCI_ETRON_HOST	BIT_ULL(49)
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_9 BIT_ULL(50)
+#define XHCI_RESET_ON_SHUTDOWN	BIT_ULL(51)
 
 	unsigned int		num_active_eps;
 	unsigned int		limit_active_eps;
-- 
2.52.0

Re: [PATCH V3] xhci: Reset TI USB controller on xhci shutdown

[Michal Pecio]

On Wed, 21 Oct 2026 12:06:08 -0400, wenxiong@linux.ibm.com wrote:
> From: Wen Xiong <wenxiong@linux.ibm.com>
> 
> Fixes kexec boot. Without a hard reset, TI pci usb chips will fail to
> initialize in a kexec booted kernel.
> 
> Signed-off-by: Wen Xiong <wenxiong@linux.ibm.com>

[ Adding linux-pci and Bjorn Helgaas ]

I tried to make this code a bit more "proper", by moving the
pci_reset_function_locked() call to xhci-pci.c from xhci.c.

I found that when I actually run this, I get a warning from PCI:

  unlocked secondary bus reset via: __pci_reset_function_locked

Bjorn, any tips what would be a proper way to whack a malfunctioning
PCI device with a heavy hammer to ensure it will work after kexec?
Seems we have pci_reset_function(), which locks the parent bridge for
us, but it also preserves some "state". Do we want that?

I'm also starting to wonder if we shouldn't do this reset after kexec,
to cover for kdump. Or maybe both, because shutdown() is supposed to
quiesce the chip and keep it from doing DMA, and we have no idea what
such chip is doing (if anything) when it refuses to halt.

Thanks,
Michal

> [...]
> +	/*
> +	 * TI xHCI controllers fail to initialize in a kexec
> +	 * kernel without a PCI function reset
> +	 */
> +	if (err && (xhci->quirks & XHCI_RESET_ON_SHUTDOWN))
> +		pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
> [...]

Re: [PATCH V3] xhci: Reset TI USB controller on xhci shutdown

[Wen Xiong]

> 
> I tried to make this code a bit more "proper", by moving the
> pci_reset_function_locked() call to xhci-pci.c from xhci.c.
> 
> I found that when I actually run this, I get a warning from PCI:
> 
>   unlocked secondary bus reset via: __pci_reset_function_locked
> 

Thanks for your reviewing!
Can we do?
if device is TI/0x8241 device, we just reset it in xhci-pci.c.
We don't need to bother other USB devices.

Thanks,
Wendy
> Bjorn, any tips what would be a proper way to whack a malfunctioning
> PCI device with a heavy hammer to ensure it will work after kexec?
> Seems we have pci_reset_function(), which locks the parent bridge for
> us, but it also preserves some "state". Do we want that?
> 
> I'm also starting to wonder if we shouldn't do this reset after kexec,
> to cover for kdump. Or maybe both, because shutdown() is supposed to
> quiesce the chip and keep it from doing DMA, and we have no idea what
> such chip is doing (if anything) when it refuses to halt.
> 
> Thanks,
> Michal
> 
>> [...]
>> +	/*
>> +	 * TI xHCI controllers fail to initialize in a kexec
>> +	 * kernel without a PCI function reset
>> +	 */
>> +	if (err && (xhci->quirks & XHCI_RESET_ON_SHUTDOWN))
>> +		pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
>> [...]