From: Mario Limonciello mario.limonciello@amd.com
[ Upstream commit 65fc0fc137b5da3ee1f4ca4f61050fcb203d7582 ]
When a USB4 dock is unplugged from a system it won't respond to ring events. The PCI core handles the surprise removal event and notifies all PCI drivers. The XHCI PCI driver sets a flag that the device is being removed, and when the device stops responding a flag is also added to indicate it's dying.
When that flag is set don't bother to show warnings about a missing controller.
Signed-off-by: Mario Limonciello mario.limonciello@amd.com Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Acked-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20250717073107.488599-3-mathias.nyman@linux.intel.... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis of this commit, here is my assessment:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **Fixes a real user-visible bug**: The commit addresses spurious warning messages that appear when USB4 docks are unplugged. When a USB4 dock is removed, the controller becomes inaccessible (reads return 0xffffffff), but the driver still attempts operations and logs warnings that are misleading to users.
2. **Small and contained fix**: The changes are minimal - only adding conditional checks before logging warnings in two functions (`xhci_halt()` and `xhci_reset()`). The fix simply checks if the `XHCI_STATE_DYING` flag is set before printing warnings.
3. **Low risk of regression**: The changes only affect warning messages, not functional behavior. The actual error paths and return values remain unchanged. This is a purely cosmetic fix that improves the user experience by avoiding confusing warnings during expected hardware removal scenarios.
4. **Clear problem and solution**: The commit message clearly describes the issue (USB4 dock removal causes warnings) and the solution (suppress warnings when controller is dying). The code changes directly implement this solution.
5. **Affects common hardware scenarios**: USB4 docks are becoming increasingly common, and surprise removal is a normal use case that shouldn't generate alarming warnings in system logs.
6. **Follows stable tree criteria**: This is a bug fix that improves user experience without introducing new features or making architectural changes. It's exactly the type of fix that stable trees are meant to include.
The code changes show: - In `xhci_halt()`: Added check `if (!(xhci->xhc_state & XHCI_STATE_DYING))` before `xhci_warn()` - In `xhci_reset()`: Added the same check before another `xhci_warn()`
Both changes prevent warning messages when the controller is already marked as dying, which is the expected state during USB4 dock removal. This is a classic example of a stable-worthy fix that improves system behavior without functional changes.
drivers/usb/host/xhci.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index cb9f35acb1f9..cb29aa49ceba 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -120,7 +120,8 @@ int xhci_halt(struct xhci_hcd *xhci) ret = xhci_handshake(&xhci->op_regs->status, STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC); if (ret) { - xhci_warn(xhci, "Host halt failed, %d\n", ret); + if (!(xhci->xhc_state & XHCI_STATE_DYING)) + xhci_warn(xhci, "Host halt failed, %d\n", ret); return ret; }
@@ -179,7 +180,8 @@ int xhci_reset(struct xhci_hcd *xhci, u64 timeout_us) state = readl(&xhci->op_regs->status);
if (state == ~(u32)0) { - xhci_warn(xhci, "Host not accessible, reset failed.\n"); + if (!(xhci->xhc_state & XHCI_STATE_DYING)) + xhci_warn(xhci, "Host not accessible, reset failed.\n"); return -ENODEV; }