From d462c8e89e84bfb6417e6b4c88e0cb7cc747ba41 Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Fri, 17 Apr 2026 10:51:46 +0200 Subject: [PATCH 1/7] PCI: Stop setting cached power state to 'unknown' on unbind When a PCI device is unbound from its driver, pci_device_remove() sets the cached power state in pci_dev->current_state to PCI_UNKNOWN. This was introduced by commit 2449e06a5696 ("PCI: reset pci device state to unknown state for resume") to invalidate the cached power state in case the system is subsequently put to sleep. For bound devices, the cached power state is set to PCI_UNKNOWN in pci_pm_suspend_noirq(), immediately before entering system sleep. Extend to unbound devices for consistency. This obviates the need to change the cached power state on unbind, so stop doing so. Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/af7d11d3ceb231acc90829f7a5c8400c2446744f.1776415510.git.lukas@wunner.de --- drivers/pci/pci-driver.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index d10ece0889f0..2bfefd8db526 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -512,13 +512,6 @@ static void pci_device_remove(struct device *dev) /* Undo the runtime PM settings in local_pci_probe() */ pm_runtime_put_sync(dev); - /* - * If the device is still on, set the power state as "unknown", - * since it might change by the next time we load the driver. - */ - if (pci_dev->current_state == PCI_D0) - pci_dev->current_state = PCI_UNKNOWN; - /* * We would love to complain here if pci_dev->is_enabled is set, that * the driver should have called pci_disable_device(), but the @@ -893,7 +886,7 @@ static int pci_pm_suspend_noirq(struct device *dev) if (!pm) { pci_save_state(pci_dev); - goto Fixup; + goto set_unknown; } if (pm->suspend_noirq) { @@ -945,6 +938,7 @@ static int pci_pm_suspend_noirq(struct device *dev) goto Fixup; } +set_unknown: pci_pm_set_unknown_state(pci_dev); /* From ee7471fe968d210939be9046089a924cd23c8c3b Mon Sep 17 00:00:00 2001 From: Marco Nenciarini Date: Fri, 17 Apr 2026 15:24:36 +0200 Subject: [PATCH 2/7] PCI: Skip Resizable BAR restore on read error pci_restore_rebar_state() uses the Resizable BAR Control register to decide how many BARs to restore (nbars) and which BAR each iteration addresses (bar_idx). When a device does not respond, config reads typically return PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx both evaluate to 7, past the spec's valid ranges for both fields. pci_resource_n() then returns an unrelated resource slot, whose size is used to derive a nonsensical value written back to the Resizable BAR Control register. Bail out if any Resizable BAR Control read returns PCI_ERROR_RESPONSE. No further BARs are touched, which is safe because a config read that returns PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is pointless. Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume") Signed-off-by: Marco Nenciarini Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/666cac19b5daa0ab0e0ab64454e76b4d24465dbd.1776429882.git.mnencia@kcore.it --- drivers/pci/rebar.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c index 39f8cf3b70d5..11965947c4cb 100644 --- a/drivers/pci/rebar.c +++ b/drivers/pci/rebar.c @@ -231,6 +231,9 @@ void pci_restore_rebar_state(struct pci_dev *pdev) return; pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl); + if (PCI_POSSIBLE_ERROR(ctrl)) + return; + nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl); for (i = 0; i < nbars; i++, pos += 8) { @@ -238,6 +241,9 @@ void pci_restore_rebar_state(struct pci_dev *pdev) int bar_idx, size; pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl); + if (PCI_POSSIBLE_ERROR(ctrl)) + return; + bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX; res = pci_resource_n(pdev, bar_idx); size = pci_rebar_bytes_to_size(resource_size(res)); From f34f1712229d71ce4286440fef12526fd4590b37 Mon Sep 17 00:00:00 2001 From: Marco Nenciarini Date: Fri, 17 Apr 2026 15:24:37 +0200 Subject: [PATCH 3/7] PCI/IOV: Skip VF Resizable BAR restore on read error sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control register to decide how many VF BARs to restore (nbars) and which VF BAR each iteration addresses (bar_idx). bar_idx indexes into dev->sriov->barsz[], which has only PCI_SRIOV_NUM_BARS (6) entries. When a device does not respond, config reads typically return PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx both evaluate to 7. The barsz[] access then goes out of bounds. UBSAN reports this as: UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51 index 7 is out of range for type 'resource_size_t [6]' Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that stopped responding during a failed GC6 power state exit. The subsequent pci_restore_state() invoked sriov_restore_vf_rebar_state() while config reads returned 0xffffffff, triggering the splat. Bail out if any VF Resizable BAR Control read returns PCI_ERROR_RESPONSE. No further VF BARs are touched, which is safe because a config read that returns PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is pointless. This mirrors the guard in pci_restore_rebar_state(). Fixes: 5a8f77e24a30 ("PCI/IOV: Restore VF resizable BAR state after reset") Signed-off-by: Marco Nenciarini Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/44a4ae53ec2825816b816c85cd378430d9a95cc6.1776429882.git.mnencia@kcore.it --- drivers/pci/iov.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index 91ac4e37ecb9..08df9bace13d 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -938,12 +938,18 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev) return; pci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl); + if (PCI_POSSIBLE_ERROR(ctrl)) + return; + nbars = FIELD_GET(PCI_VF_REBAR_CTRL_NBAR_MASK, ctrl); for (i = 0; i < nbars; i++, pos += 8) { int bar_idx, size; pci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl); + if (PCI_POSSIBLE_ERROR(ctrl)) + return; + bar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl); size = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]); ctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE; From ada02d0894fd0ae65bda4d5fbf88dad0a6cb0788 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Tue, 19 May 2026 13:41:20 +0530 Subject: [PATCH 4/7] PCI: Add pci_suspend_retains_context() to check if device state is preserved during suspend Currently, PCI endpoint drivers (e.g. nvme) use pm_suspend_via_firmware() to check whether device state is preserved during system suspend. If firmware will be invoked at the end of suspend, we don't know whether devices will retain their internal state. But device context might be lost due to platform issues as well. Having those checks in endpoint drivers will not scale and will cause a lot of code duplication. Add pci_suspend_retains_context() as a sole point of truth that the endpoint drivers can rely on to check whether they can expect the device context to be retained or not. If pci_suspend_retains_context() returns 'false', drivers need to prepare for context loss by performing actions such as resetting the device, saving the context, shutting it down etc. If it returns 'true', drivers do not need to perform any special action and can leave the device in active state. Right now, this API only incorporates pm_suspend_via_firmware(), but will be extended in future commits. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260519-l1ss-fix-v2-1-b2c3a4bdeb15@oss.qualcomm.com --- drivers/pci/pci.c | 23 +++++++++++++++++++++++ include/linux/pci.h | 7 +++++++ 2 files changed, 30 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 8f7cfcc00090..86961551ec51 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "pci.h" DEFINE_MUTEX(pci_slot_mutex); @@ -2899,6 +2900,28 @@ void pci_config_pm_runtime_put(struct pci_dev *pdev) pm_runtime_put_sync(parent); } +/** + * pci_suspend_retains_context - Check if the platform can retain the device + * context during system suspend + * @pdev: PCI device to check + * + * Return: true if the platform can guarantee to retain the device context, + * false otherwise. + */ +bool pci_suspend_retains_context(struct pci_dev *pdev) +{ + /* + * If the platform firmware (like ACPI) is involved at the end of + * system suspend, device context may not be retained. + */ + if (pm_suspend_via_firmware()) + return false; + + /* Assume that the context is retained by default */ + return true; +} +EXPORT_SYMBOL_GPL(pci_suspend_retains_context); + static const struct dmi_system_id bridge_d3_blacklist[] = { #ifdef CONFIG_X86 { diff --git a/include/linux/pci.h b/include/linux/pci.h index 2c4454583c11..f60f9e4e7b39 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -2086,6 +2086,8 @@ pci_release_mem_regions(struct pci_dev *pdev) pci_select_bars(pdev, IORESOURCE_MEM)); } +bool pci_suspend_retains_context(struct pci_dev *pdev); + #else /* CONFIG_PCI is not enabled */ static inline void pci_set_flags(int flags) { } @@ -2244,6 +2246,11 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs, static inline void pci_free_irq_vectors(struct pci_dev *dev) { } + +static inline bool pci_suspend_retains_context(struct pci_dev *pdev) +{ + return true; +} #endif /* CONFIG_PCI */ /* Include architecture-dependent settings and functions */ From b583b8fda6ddcf81fe1b02bec0d3c7fb43efc6de Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Tue, 19 May 2026 13:41:21 +0530 Subject: [PATCH 5/7] PCI: Indicate context lost if L1SS exit is broken during resume from system suspend Per PCIe v7.0, sec 5.5.3.3.1, when exiting L1.2 due to an endpoint asserting CLKREQ# signal, the REFCLK must be turned on within the latency advertised in the LTR message. This requirement applies to L1.1 as well. On some platforms like Qcom, these requirements are satisfied during OS runtime, but not while resuming from the system suspend. This happens because the PCIe RC driver may remove all resource votes and turn off the PHY analog circuitry during suspend to maximize power savings while keeping the link in L1SS. Consequently, when the endpoint asserts CLKREQ# to wake up, the RC driver must restore the PHY and enable the REFCLK. When this recovery process exceeds the L1SS exit latency time (roughly L10_REFCLK_ON + T_COMMONMODE), the endpoint may treat it as a fatal condition and trigger Link Down (LDn). This results in a reset that destroys the internal device state. So to indicate this platform limitation to the client drivers, introduce a new flag 'pci_host_bridge::broken_l1ss_resume' and check it in pci_suspend_retains_context(). If the flag is set by the RC driver, the API will return 'false' indicating the client drivers that the device context may not be retained and the drivers must be prepared for context loss. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260519-l1ss-fix-v2-2-b2c3a4bdeb15@oss.qualcomm.com --- drivers/pci/pci.c | 12 ++++++++++++ include/linux/pci.h | 2 ++ 2 files changed, 14 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 86961551ec51..2f7e7e186b47 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2910,6 +2910,8 @@ void pci_config_pm_runtime_put(struct pci_dev *pdev) */ bool pci_suspend_retains_context(struct pci_dev *pdev) { + struct pci_host_bridge *bridge = pci_find_host_bridge(pdev->bus); + /* * If the platform firmware (like ACPI) is involved at the end of * system suspend, device context may not be retained. @@ -2917,6 +2919,16 @@ bool pci_suspend_retains_context(struct pci_dev *pdev) if (pm_suspend_via_firmware()) return false; + /* + * Some host bridges power off the PHY to enter deep low-power + * modes during system suspend. Exiting L1SS from this condition + * may violate timing requirements and result in Link Down (LDn), + * which causes a reset of the device. On such platforms, the + * endpoint must be prepared for context loss. + */ + if (bridge && bridge->broken_l1ss_resume) + return false; + /* Assume that the context is retained by default */ return true; } diff --git a/include/linux/pci.h b/include/linux/pci.h index f60f9e4e7b39..4fee00ec59d7 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -660,6 +660,8 @@ struct pci_host_bridge { unsigned int preserve_config:1; /* Preserve FW resource setup */ unsigned int size_windows:1; /* Enable root bus sizing */ unsigned int msi_domain:1; /* Bridge wants MSI domain */ + unsigned int broken_l1ss_resume:1; /* Resuming from L1SS during + system suspend is broken */ /* Resource alignment requirements */ resource_size_t (*align_resource)(struct pci_dev *dev, From ced835ae1f62c5a316a4229dde5762c63d0ac27b Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Tue, 19 May 2026 13:41:22 +0530 Subject: [PATCH 6/7] PCI: qcom: Indicate broken L1SS exit during resume from system suspend Qcom PCIe RCs can successfully exit from L1SS during OS runtime. However, during system suspend, the Qcom PCIe RC driver may remove all resource votes and turn off the PHY to maximize power savings. Consequently, when the host is in system suspend with the link in L1SS and the endpoint asserts CLKREQ#, the RC driver must restore the PHY and enable the REFCLK. This recovery process causes the L1SS exit latency time to be exceeded (roughly L10_REFCLK_ON + T_COMMONMODE). If the RC driver were to retain all votes during suspend, L1SS exit would succeed without issue but at the expense of higher power consumption. When the host fails to move the link from L1SS to L0 within the L10_REFCLK_ON + T_COMMONMODE time, the endpoint may treat it as a fatal condition and trigger Link Down (LDn) during resume. This LDn results in a reset that destroys the internal device state. To ensure that the client drivers can properly handle this scenario, let them know about this platform limitation by setting the 'pci_host_bridge::broken_l1ss_resume' flag. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260519-l1ss-fix-v2-3-b2c3a4bdeb15@oss.qualcomm.com --- drivers/pci/controller/dwc/pcie-qcom.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index af6bf5cce65b..a0b59b4ef1d2 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1368,6 +1368,19 @@ static void qcom_pcie_host_post_init(struct dw_pcie_rp *pp) struct dw_pcie *pci = to_dw_pcie_from_pp(pp); struct qcom_pcie *pcie = to_qcom_pcie(pci); + /* + * During system suspend, the Qcom RC driver may turn off the + * analog circuitry of PHY and remove controller votes to save + * power. If the link is in L1SS and the endpoint asserts CLKREQ# + * to exit L1SS, the time required to wake the system and restore + * the PHY/REFCLK may exceed the L1SS exit timing (L10_REFCLK_ON + + * T_COMMONMODE), resulting in Link Down (LDn) and a reset of the + * endpoint. Set this flag to indicate this limitation to client + * drivers so that they can avoid relying on device state being + * preserved during system suspend. + */ + pp->bridge->broken_l1ss_resume = true; + if (pcie->cfg->ops->host_post_init) pcie->cfg->ops->host_post_init(pcie); } From 748a927e081bffc9a9be17b4d96088515e1c5f01 Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Tue, 19 May 2026 13:41:23 +0530 Subject: [PATCH 7/7] nvme-pci: Use pci_suspend_retains_context() during suspend pci_suspend_retains_context() lets PCI client drivers know if the platform can retain the device context during suspend. This is decided based on several factors like: - Firmware involvement at the end of suspend - Any platform limitation in waking from low power state (e.g., L1SS) This API may be extended in the future to cover other platform specific issues impacting the device low power mode during system suspend. Use this API instead of checks like pm_suspend_via_firmware(). When pci_suspend_retains_context() returns false, assume the platform cannot retain the context and shutdown the controller. If it returns true, assume that the context will be retained and keep the device in low power mode. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260519-l1ss-fix-v2-4-b2c3a4bdeb15@oss.qualcomm.com --- drivers/nvme/host/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index db5fc9bf6627..a6664983ce5d 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3915,6 +3915,7 @@ static int nvme_suspend(struct device *dev) * use host managed nvme power settings for lowest idle power if * possible. This should have quicker resume latency than a full device * shutdown. But if the firmware is involved after the suspend or the + * platform has any limitation in waking from low power states or the * device does not support any non-default power states, shut down the * device fully. * @@ -3923,7 +3924,7 @@ static int nvme_suspend(struct device *dev) * down, so as to allow the platform to achieve its minimum low-power * state (which may not be possible if the link is up). */ - if (pm_suspend_via_firmware() || !ctrl->npss || + if (!pci_suspend_retains_context(pdev) || !ctrl->npss || !pcie_aspm_enabled(pdev) || (ndev->ctrl.quirks & NVME_QUIRK_SIMPLE_SUSPEND)) return nvme_disable_prepare_reset(ndev, true);