All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: manivannan.sadhasivam@oss.qualcomm.com
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Keith Busch" <kbusch@kernel.org>, "Jens Axboe" <axboe@kernel.dk>,
	"Christoph Hellwig" <hch@lst.de>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 0/4] PCI: Introduce pci_dev_suspend_retention_supported() API
Date: Thu, 16 Apr 2026 14:11:11 -0500	[thread overview]
Message-ID: <20260416191111.GA21551@bhelgaas> (raw)
In-Reply-To: <20260414-l1ss-fix-v1-0-adbb4555b5ab@oss.qualcomm.com>

[+cc Rafael]

On Tue, Apr 14, 2026 at 09:29:38PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> This series introduces a new PCI API
> pci_dev_suspend_retention_supported() 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 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.

I don't know what pm_suspend_via_firmware() means.  The kernel-doc
says "platform firmware is going to be invoked at the end of the
system-wide power management transition," but that doesn't say
anything about what firmware might do or what it means to drivers.

Based on d916b1be94b6 ("nvme-pci: use host managed power state for
suspend"), which used it in nvme_suspend(), I guess the assumption is
that pm_suspend_via_firmware() means the device might be put in D3cold
and lose all its internal state, and conversely,
!pm_suspend_via_firmware() means the device will *never* be put in a
low-power state that loses internal state.

> 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@oss.qualcomm.com>
> ---
> Manivannan Sadhasivam (4):
>       PCI: Introduce an API to check if RC/platform can retain device context during suspend
>       PCI: Indicate context lost if L1ss exit is broken during resume from system suspend
>       PCI: qcom: Indicate broken L1ss exit during resume from system suspend
>       nvme-pci: Use pci_dev_suspend_retention_supported() API during suspend
> 
>  drivers/nvme/host/pci.c                |  3 ++-
>  drivers/pci/controller/dwc/pcie-qcom.c | 11 +++++++++++
>  drivers/pci/pci.c                      | 34 ++++++++++++++++++++++++++++++++++
>  include/linux/pci.h                    |  9 +++++++++
>  4 files changed, 56 insertions(+), 1 deletion(-)
> ---
> base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
> change-id: 20260414-l1ss-fix-6c9cf2451944
> 
> Best regards,
> --  
> Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> 

  parent reply	other threads:[~2026-04-16 19:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 15:59 [PATCH 0/4] PCI: Introduce pci_dev_suspend_retention_supported() API Manivannan Sadhasivam
2026-04-14 15:59 ` Manivannan Sadhasivam via B4 Relay
2026-04-14 15:59 ` [PATCH 1/4] PCI: Introduce an API to check if RC/platform can retain device context during suspend Manivannan Sadhasivam
2026-04-14 15:59   ` Manivannan Sadhasivam via B4 Relay
2026-04-16 19:18   ` Bjorn Helgaas
2026-04-17 11:11     ` Manivannan Sadhasivam
2026-05-07 23:02       ` Bjorn Helgaas
2026-05-11  5:15         ` Manivannan Sadhasivam
2026-04-14 15:59 ` [PATCH 2/4] PCI: Indicate context lost if L1ss exit is broken during resume from system suspend Manivannan Sadhasivam
2026-04-14 15:59   ` Manivannan Sadhasivam via B4 Relay
2026-04-14 15:59 ` [PATCH 3/4] PCI: qcom: Indicate broken L1ss exit " Manivannan Sadhasivam
2026-04-14 15:59   ` Manivannan Sadhasivam via B4 Relay
2026-04-16 19:20   ` Bjorn Helgaas
2026-04-17 12:06     ` Manivannan Sadhasivam
2026-04-17 22:26       ` Bjorn Helgaas
2026-04-18  5:39         ` Manivannan Sadhasivam
2026-04-20 20:49           ` Bjorn Helgaas
2026-04-21 17:11             ` Manivannan Sadhasivam
2026-04-22 23:49               ` Bjorn Helgaas
2026-04-23 15:15                 ` Manivannan Sadhasivam
2026-04-14 15:59 ` [PATCH 4/4] nvme-pci: Use pci_dev_suspend_retention_supported() API during suspend Manivannan Sadhasivam
2026-04-14 15:59   ` Manivannan Sadhasivam via B4 Relay
2026-04-22  6:33   ` Christoph Hellwig
2026-04-16 19:11 ` Bjorn Helgaas [this message]
2026-04-17 11:04   ` [PATCH 0/4] PCI: Introduce pci_dev_suspend_retention_supported() API Manivannan Sadhasivam
2026-04-17 22:29     ` Bjorn Helgaas
2026-04-18  5:16       ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260416191111.GA21551@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bhelgaas@google.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=manivannan.sadhasivam@oss.qualcomm.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.