[PATCH v2 0/4] PCI: Introduce pci_suspend_retains_context() API

Brian Norris briannorris at chromium.org
Mon Jun 1 12:16:18 PDT 2026


On Tue, May 19, 2026 at 01:41:19PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> Hi all,
> 
> This series introduces a new PCI API, pci_suspend_retains_context() to
> let the client drivers know whether they can expect context retention across
> suspend/resume or not and uses it in the NVMe PCI host driver.
> 
> This new API is targeted to abstract the PCI power management details away from
> the client drivers. This is needed because client drivers like NVMe make use of
> APIs such as pm_suspend_via_firmware() and decide to keep the device in low
> power mode if this API returns 'false'. But some platforms may have other
> limitations like in the case of Qcom, where if the RC driver removes the PCIe RC
> resource vote to allow the SoC to enter low power mode, it cannot reliably exit
> the L1ss state when the endpoint asserts CLKREQ#. So in this case also, the
> client drivers cannot keep the device in low power state during suspend and
> expect context retention.
> 
> And these limitations may just keep adding in the future. Without a unified
> API, the client drivers have to implement their own logic which may cause code
> duplication and may also lead to drivers missing some of the platform
> limitations.
> 
> Once this series gets merged, we can extend this API usage to other client
> drivers as well.
> 
> Testing
> =======
> 
> This series is tested on Qualcomm Hamoa based Lenovo Thinkpad T14s latop with
> NVMe drive.
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam at oss.qualcomm.com>

FWIW, this was already applied to pci/next for v7.2, but I'll add that
it seems this resolves what appeared as a regression in v7.0 for me when
using a Qualcomm SC7280-based laptop
(arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dts):

report: https://lore.kernel.org/linux-pci/ahC8Pyuatu_AvnZp@google.com/
test notes: https://lore.kernel.org/linux-pci/ah3XLfI7E39B1UPh@google.com/

In short, my NVMe failed to resume from suspend-to-mem:

[   58.384442] nvme 0001:01:00.0: Unable to change power state from unknown to D0, device inaccessible
...
[   68.875606] nvme 0001:01:00.0: PM: **** DPM device timeout ****

Notably, this regression bisected to commit eaf290c404f7 ("PCI: dwc:
Enable MSI affinity support"), though I'm still not quite sure why.

Anyway, for $subject series, I'll provide my late tags:

Closes: https://lore.kernel.org/linux-pci/ahC8Pyuatu_AvnZp@google.com/
Tested-by: Brian Norris <briannorris at chromium.org>



More information about the Linux-nvme mailing list