* [PATCH AUTOSEL 6.6 07/59] usb: xhci: Avoid showing warnings for dying controller
2025-08-04 0:33 [PATCH AUTOSEL 6.6 01/59] usb: xhci: print xhci->xhc_state when queue_command failed Sasha Levin
@ 2025-08-04 0:33 ` Sasha Levin
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 08/59] usb: xhci: Set avg_trb_len = 8 for EP0 during Address Device Command Sasha Levin
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Sasha Levin @ 2025-08-04 0:33 UTC (permalink / raw)
To: patches, stable
Cc: Mario Limonciello, Mathias Nyman, Greg Kroah-Hartman, Sasha Levin,
mathias.nyman, linux-usb
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.com
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 ce38cd2435c8..f5e170fe5f79 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -119,7 +119,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;
}
@@ -178,7 +179,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;
}
--
2.39.5
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH AUTOSEL 6.6 08/59] usb: xhci: Set avg_trb_len = 8 for EP0 during Address Device Command
2025-08-04 0:33 [PATCH AUTOSEL 6.6 01/59] usb: xhci: print xhci->xhc_state when queue_command failed Sasha Levin
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 07/59] usb: xhci: Avoid showing warnings for dying controller Sasha Levin
@ 2025-08-04 0:33 ` Sasha Levin
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 09/59] usb: xhci: Avoid showing errors during surprise removal Sasha Levin
2025-08-04 0:34 ` [PATCH AUTOSEL 6.6 46/59] usb: typec: intel_pmc_mux: Defer probe if SCU IPC isn't present Sasha Levin
3 siblings, 0 replies; 5+ messages in thread
From: Sasha Levin @ 2025-08-04 0:33 UTC (permalink / raw)
To: patches, stable
Cc: Jay Chen, Mathias Nyman, Greg Kroah-Hartman, Sasha Levin,
mathias.nyman, linux-usb
From: Jay Chen <shawn2000100@gmail.com>
[ Upstream commit f72b9aa821a2bfe4b6dfec4be19f264d0673b008 ]
There is a subtle contradiction between sections of the xHCI 1.2 spec
regarding the initialization of Input Endpoint Context fields. Section
4.8.2 ("Endpoint Context Initialization") states that all fields should
be initialized to 0. However, Section 6.2.3 ("Endpoint Context", p.453)
specifies that the Average TRB Length (avg_trb_len) field shall be
greater than 0, and explicitly notes (p.454): "Software shall set
Average TRB Length to '8' for control endpoints."
Strictly setting all fields to 0 during initialization conflicts with
the specific recommendation for control endpoints. In practice, setting
avg_trb_len = 0 is not meaningful for the hardware/firmware, as the
value is used for bandwidth calculation.
Motivation: Our company is developing a custom Virtual xHC hardware
platform that strictly follows the xHCI spec and its recommendations.
During validation, we observed that enumeration fails and a parameter
error (TRB Completion Code = 5) is reported if avg_trb_len for EP0 is
not set to 8 as recommended by Section 6.2.3. This demonstrates the
importance of assigning a meaningful, non-zero value to avg_trb_len,
even in virtualized or emulated environments.
This patch explicitly sets avg_trb_len to 8 for EP0 in
xhci_setup_addressable_virt_dev(), as recommended in Section 6.2.3, to
prevent potential issues with xHCI host controllers that enforce the
spec strictly.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220033
Signed-off-by: Jay Chen <shawn2000100@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250717073107.488599-4-mathias.nyman@linux.intel.com
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 the commit and code, here's my assessment:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Fixes a real bug**: The commit addresses a specification compliance
issue where setting `avg_trb_len = 0` for EP0 (control endpoint)
violates the xHCI 1.2 specification. Section 6.2.3 explicitly states
that Average TRB Length shall be greater than 0 and specifically
recommends setting it to 8 for control endpoints.
2. **Small and contained fix**: The change is minimal - just adding a
single line:
```c
ep0_ctx->tx_info = cpu_to_le32(EP_AVG_TRB_LENGTH(8));
```
This sets the average TRB length field to 8 as recommended by the
spec.
3. **Prevents hardware failures**: The commit message indicates this
causes actual enumeration failures with parameter errors (TRB
Completion Code = 5) on hardware that strictly follows the xHCI
specification. This means real devices can fail to enumerate without
this fix.
4. **No architectural changes**: This is a simple initialization fix
that doesn't change any architectural aspects of the driver. It only
ensures proper initialization of a field that was previously left at
0.
5. **Low regression risk**: Setting avg_trb_len to 8 for control
endpoints follows the xHCI specification recommendation. Existing
hardware that doesn't strictly check this value will continue to
work, while hardware that does enforce the spec will now work
correctly.
6. **Clear bug with clear fix**: The contradiction between spec sections
is well-documented in the commit message, and the fix directly
addresses this by following the more specific recommendation for
control endpoints.
The commit fixes a specification compliance bug that can cause real
hardware failures during USB device enumeration. The fix is minimal,
follows the xHCI specification, and has very low risk of causing
regressions, making it an ideal candidate for stable backporting.
drivers/usb/host/xhci-mem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index cceb69d4f61e..b51464eeac46 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1182,6 +1182,8 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *ud
ep0_ctx->deq = cpu_to_le64(dev->eps[0].ring->first_seg->dma |
dev->eps[0].ring->cycle_state);
+ ep0_ctx->tx_info = cpu_to_le32(EP_AVG_TRB_LENGTH(8));
+
trace_xhci_setup_addressable_virt_device(dev);
/* Steps 7 and 8 were done in xhci_alloc_virt_device() */
--
2.39.5
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH AUTOSEL 6.6 09/59] usb: xhci: Avoid showing errors during surprise removal
2025-08-04 0:33 [PATCH AUTOSEL 6.6 01/59] usb: xhci: print xhci->xhc_state when queue_command failed Sasha Levin
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 07/59] usb: xhci: Avoid showing warnings for dying controller Sasha Levin
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 08/59] usb: xhci: Set avg_trb_len = 8 for EP0 during Address Device Command Sasha Levin
@ 2025-08-04 0:33 ` Sasha Levin
2025-08-04 0:34 ` [PATCH AUTOSEL 6.6 46/59] usb: typec: intel_pmc_mux: Defer probe if SCU IPC isn't present Sasha Levin
3 siblings, 0 replies; 5+ messages in thread
From: Sasha Levin @ 2025-08-04 0:33 UTC (permalink / raw)
To: patches, stable
Cc: Mario Limonciello, Mathias Nyman, Greg Kroah-Hartman, Sasha Levin,
mathias.nyman, linux-usb
From: Mario Limonciello <mario.limonciello@amd.com>
[ Upstream commit 4b9c60e440525b729ac5f071e00bcee12e0a7e84 ]
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 as well.
When that flag is set don't show messages in the cleanup path for
marking the controller dead.
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-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now let me analyze this commit properly:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Fixes a user-visible issue**: The commit addresses spurious error
messages that appear when USB4 docks are unplugged. The original code
shows `xhci_err(xhci, "xHCI host controller not responding, assume
dead\n")` even during expected surprise removals, which can confuse
users and fill system logs unnecessarily.
2. **Small and contained fix**: The change is minimal - it only adds a
local `notify` variable and conditionalizes two operations based on
whether the device is being removed:
- The error message printing (line 1384 → lines 1379-1381)
- The `usb_hc_died()` notification (reusing the same condition)
3. **No architectural changes**: This is a simple behavioral fix that
doesn't modify any data structures, APIs, or core functionality. It
merely suppresses error messages during an expected removal scenario.
4. **Clear bug fix**: The commit clearly fixes an issue where error
messages are shown during normal USB4 dock removal operations. When
`XHCI_STATE_REMOVING` is set (indicating PCI removal is in progress),
the error message is now suppressed since it's an expected condition.
5. **Low risk of regression**: The change only affects logging behavior
and maintains the same functional flow. The `usb_hc_died()` call was
already conditional on `!XHCI_STATE_REMOVING`, so this commit just
applies the same logic to the error message.
6. **Improves user experience**: USB4/Thunderbolt docks are increasingly
common, and users frequently unplug them. Avoiding spurious error
messages during normal operations is important for user experience
and log clarity.
The commit follows stable tree rules by being a minimal fix for a real
issue that affects users, without introducing new features or making
risky changes to core functionality.
drivers/usb/host/xhci-ring.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c6d89b51c678..2a74a47a1c76 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1338,12 +1338,15 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci,
*/
void xhci_hc_died(struct xhci_hcd *xhci)
{
+ bool notify;
int i, j;
if (xhci->xhc_state & XHCI_STATE_DYING)
return;
- xhci_err(xhci, "xHCI host controller not responding, assume dead\n");
+ notify = !(xhci->xhc_state & XHCI_STATE_REMOVING);
+ if (notify)
+ xhci_err(xhci, "xHCI host controller not responding, assume dead\n");
xhci->xhc_state |= XHCI_STATE_DYING;
xhci_cleanup_command_queue(xhci);
@@ -1357,7 +1360,7 @@ void xhci_hc_died(struct xhci_hcd *xhci)
}
/* inform usb core hc died if PCI remove isn't already handling it */
- if (!(xhci->xhc_state & XHCI_STATE_REMOVING))
+ if (notify)
usb_hc_died(xhci_to_hcd(xhci));
}
--
2.39.5
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH AUTOSEL 6.6 46/59] usb: typec: intel_pmc_mux: Defer probe if SCU IPC isn't present
2025-08-04 0:33 [PATCH AUTOSEL 6.6 01/59] usb: xhci: print xhci->xhc_state when queue_command failed Sasha Levin
` (2 preceding siblings ...)
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 09/59] usb: xhci: Avoid showing errors during surprise removal Sasha Levin
@ 2025-08-04 0:34 ` Sasha Levin
3 siblings, 0 replies; 5+ messages in thread
From: Sasha Levin @ 2025-08-04 0:34 UTC (permalink / raw)
To: patches, stable
Cc: Tomasz Michalec, Heikki Krogerus, Greg Kroah-Hartman, Sasha Levin,
linux-usb
From: Tomasz Michalec <tmichalec@google.com>
[ Upstream commit df9a825f330e76c72d1985bc9bdc4b8981e3d15f ]
If pmc_usb_probe is called before SCU IPC is registered, pmc_usb_probe
will fail.
Return -EPROBE_DEFER when pmc_usb_probe doesn't get SCU IPC device, so
the probe function can be called again after SCU IPC is initialized.
Signed-off-by: Tomasz Michalec <tmichalec@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250610154058.1859812-1-tmichalec@google.com
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 the commit and the kernel codebase, here's my
assessment:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Clear Bug Fix**: The commit fixes a real probe ordering issue where
`pmc_usb_probe` fails if called before the SCU IPC driver is
initialized. The current code returns `-ENODEV` which prevents the
driver from ever loading, while `-EPROBE_DEFER` allows the kernel to
retry probing later.
2. **Established Pattern**: Looking at the codebase, other Intel
platform drivers that depend on SCU IPC already use this pattern:
- `drivers/watchdog/intel-mid_wdt.c`: Returns `-EPROBE_DEFER` when
`devm_intel_scu_ipc_dev_get()` returns NULL
- `drivers/mfd/intel_soc_pmic_bxtwc.c`: Returns `-EPROBE_DEFER` in
the same scenario
- `drivers/platform/x86/intel/telemetry/pltdrv.c`: Also uses
`-EPROBE_DEFER`
3. **Small and Contained Change**: The fix is a one-line change
(`-ENODEV` → `-EPROBE_DEFER`) that only affects the error handling
path during probe. It doesn't introduce new functionality or change
any existing behavior when SCU IPC is available.
4. **No Architecture Changes**: This is purely a bug fix that corrects
incorrect error handling. It doesn't introduce new features or make
architectural changes to the driver.
5. **Minimal Risk**: The change is extremely low risk - it only affects
the error path when SCU IPC isn't yet available, and the deferred
probe mechanism is a well-established kernel pattern designed
specifically for handling driver dependencies.
6. **Real-World Impact**: Without this fix, users could experience USB
Type-C functionality failures on Intel platforms if the drivers
happen to probe in the wrong order. This is particularly problematic
on systems where driver probe order is non-deterministic.
The commit follows the stable tree rules by fixing an important bug
(probe failure due to ordering) with minimal risk and no new features.
The fact that other Intel drivers already use this pattern confirms this
is the correct approach for handling SCU IPC dependencies.
drivers/usb/typec/mux/intel_pmc_mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
index 60ed1f809130..a174ff7a9abd 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -730,7 +730,7 @@ static int pmc_usb_probe(struct platform_device *pdev)
pmc->ipc = devm_intel_scu_ipc_dev_get(&pdev->dev);
if (!pmc->ipc)
- return -ENODEV;
+ return -EPROBE_DEFER;
pmc->dev = &pdev->dev;
--
2.39.5
^ permalink raw reply related [flat|nested] 5+ messages in thread