Re: [PATCH 1/4] PCI: Introduce an API to check if RC/platform can retain device context during suspend

Re: [PATCH 1/4] PCI: Introduce an API to check if RC/platform can retain device context during suspend

[Bjorn Helgaas]

On Fri, Apr 17, 2026 at 04:41:09PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Apr 16, 2026 at 02:18:55PM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 14, 2026 at 09:29:39PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > 
> > > Currently, the PCI endpoint drivers like NVMe checks whether the device
> > > context will be retained or not during system suspend, with the help of
> > > pm_suspend_via_firmware() API.
> > > 
> > > But it is possible that the device context might be lost due to some
> > > platform limitation as well. Having those checks in the endpoint drivers
> > > will not scale and will cause a lot of code duplication.
> ...

> > > + * pci_dev_suspend_retention_supported - Check if the platform can retain the device
> > > + *					 context during system suspend
> > > + * @pdev: PCI device to check
> > > + *
> > > + * Returns true if the platform can guarantee to retain the device context,
> > > + * false otherwise.
> > > + */
> > > +bool pci_dev_suspend_retention_supported(struct pci_dev *pdev)
> > 
> > This doesn't seem like the right name.  This isn't a property of the
> > *device*; that's all determined by the PCI spec (devices must retain
> > all internal state in D0, D1, and D2, they retain it in D3hot if
> > No_Soft_Reset, and they never do in D3cold).
> > 
> > So this seems like something to do with the *platform* behavior.  It
> > sounds like this is basically a way to learn whether the device might
> > be put in D3cold on system suspend.
> 
> That's correct. But I wanted to keep it device specific, since apart
> from pm_suspend_via_firmware() there could be other issues causing
> context to be lost. Like the issue with RC, brought up in the
> successive patches. There could be chances that only one hierarchy
> might be affected. So making it device specific would give us the
> granularity.

OK, a device-specific API is fine.

Maybe it could be something like "pci_suspend_preserves_context()"?

Is it the case that suspend never uses D3cold?  If suspend ever uses
D3cold, *every* device put in D3cold will lose its context.

How would this work if suspend can use D3cold?  Can a driver (or this
API) learn whether D3cold might be used?

Re: [PATCH 1/4] PCI: Introduce an API to check if RC/platform can retain device context during suspend

[Manivannan Sadhasivam]

On Thu, May 07, 2026 at 06:02:48PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 17, 2026 at 04:41:09PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Apr 16, 2026 at 02:18:55PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Apr 14, 2026 at 09:29:39PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > 
> > > > Currently, the PCI endpoint drivers like NVMe checks whether the device
> > > > context will be retained or not during system suspend, with the help of
> > > > pm_suspend_via_firmware() API.
> > > > 
> > > > But it is possible that the device context might be lost due to some
> > > > platform limitation as well. Having those checks in the endpoint drivers
> > > > will not scale and will cause a lot of code duplication.
> > ...
> 
> > > > + * pci_dev_suspend_retention_supported - Check if the platform can retain the device
> > > > + *					 context during system suspend
> > > > + * @pdev: PCI device to check
> > > > + *
> > > > + * Returns true if the platform can guarantee to retain the device context,
> > > > + * false otherwise.
> > > > + */
> > > > +bool pci_dev_suspend_retention_supported(struct pci_dev *pdev)
> > > 
> > > This doesn't seem like the right name.  This isn't a property of the
> > > *device*; that's all determined by the PCI spec (devices must retain
> > > all internal state in D0, D1, and D2, they retain it in D3hot if
> > > No_Soft_Reset, and they never do in D3cold).
> > > 
> > > So this seems like something to do with the *platform* behavior.  It
> > > sounds like this is basically a way to learn whether the device might
> > > be put in D3cold on system suspend.
> > 
> > That's correct. But I wanted to keep it device specific, since apart
> > from pm_suspend_via_firmware() there could be other issues causing
> > context to be lost. Like the issue with RC, brought up in the
> > successive patches. There could be chances that only one hierarchy
> > might be affected. So making it device specific would give us the
> > granularity.
> 
> OK, a device-specific API is fine.
> 
> Maybe it could be something like "pci_suspend_preserves_context()"?
> 

How about, pci_suspend_retains_context()? But I'm fine with
pci_suspend_preserves_context() too.

> Is it the case that suspend never uses D3cold?  If suspend ever uses
> D3cold, *every* device put in D3cold will lose its context.
> 
> How would this work if suspend can use D3cold?  Can a driver (or this
> API) learn whether D3cold might be used?

If this API returns 'false', then the device will lose all the context during
suspend. But that's not due to D3Cold, but due to the firmware and RC issues.
One can say that losing context is equivalent to D3Cold, but this API doesn't
guarantee that the proper D3Cold transition will happen (PME_Turn_Off broadcast
and waiting for PME_To_Ack).

So I would say, drivers cannot use this API to learn about D3Cold

- Mani

-- 
மணிவண்ணன் சதாசிவம்