From: Mario Limonciello mario.limonciello@amd.com
[ Upstream commit 299fad4133677b845ce962f78c9cf75bded63f61 ]
When a device is surprise-removed (e.g., due to a dock unplug), the PCI core unconfigures all downstream devices and sets their error state to pci_channel_io_perm_failure. This marks them as disconnected via pci_dev_is_disconnected().
During device removal, the runtime PM framework may attempt to resume the device to D0 via pm_runtime_get_sync(), which calls into pci_power_up(). Since the device is already disconnected, this resume attempt is unnecessary and results in a predictable errors like this, typically when undocking from a TBT3 or USB4 dock with PCIe tunneling:
pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
Avoid powering up disconnected devices by checking their status early in pci_power_up() and returning -EIO.
Suggested-by: Lukas Wunner lukas@wunner.de Signed-off-by: Mario Limonciello mario.limonciello@amd.com [bhelgaas: add typical message] Signed-off-by: Bjorn Helgaas bhelgaas@google.com Reviewed-by: Lukas Wunner lukas@wunner.de Reviewed-by: Ilpo Järvinen ilpo.jarvinen@linux.intel.com Acked-by: Rafael J. Wysocki rafael@kernel.org Link: https://patch.msgid.link/20250909031916.4143121-1-superm1@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES - The new guard in `drivers/pci/pci.c:1321-1324` checks `pci_dev_is_disconnected()` before touching PCI PM registers, so surprise-removed devices short-circuit with `-EIO` while keeping `current_state = PCI_D3cold`. This prevents the guaranteed `"Unable to change power state..."` error emitted when `pci_read_config_word()` hits a vanished device (see `drivers/pci/pci.c:1326-1331`), which currently spams logs whenever users undock TBT3/USB4 systems. - Callers already expect a negative return in this scenario—the pre- change path hit the same `-EIO` branch after the failing config read—so observable behaviour stays the same aside from eliminating the noisy and misleading error message. `pci_set_full_power_state()` and runtime PM resume paths therefore retain their semantics but avoid futile config accesses. - The fix is narrowly scoped to PCI PM, introduces no architectural churn, and relies only on long-standing helpers present in supported stables (confirmed `pci_dev_is_disconnected()` in tags like `p-6.6`). It neither alters power-state transitions for healthy devices nor affects platforms lacking PM caps because the new check comes after the existing `!dev->pm_cap` fallback. - Avoiding config transactions on removed hardware reduces the chance of host controller complaints and matches other PCI core code that tests `pci_dev_is_disconnected()` before issuing requests, making this a low-risk, high-signal bug fix well suited for stable backporting.
Natural next step: 1) Queue the patch for the targeted stable series after double-checking those trees already expose `pci_dev_is_disconnected()` in `include/linux/pci.h`.
drivers/pci/pci.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b0f4d98036cdd..036511f5b2625 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1374,6 +1374,11 @@ int pci_power_up(struct pci_dev *dev) return -EIO; }
+ if (pci_dev_is_disconnected(dev)) { + dev->current_state = PCI_D3cold; + return -EIO; + } + pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr); if (PCI_POSSIBLE_ERROR(pmcsr)) { pci_err(dev, "Unable to change power state from %s to D0, device inaccessible\n",