From: Bjorn Helgaas <helgaas@kernel.org>
To: "Hongxing Zhu (OSS)" <hongxing.zhu@oss.nxp.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
Frank Li <frank.li@nxp.com>,
"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"kwilczynski@kernel.org" <kwilczynski@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"festevam@gmail.com" <festevam@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"imx@lists.linux.dev" <imx@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Hongxing Zhu <hongxing.zhu@nxp.com>
Subject: Re: [PATCH v2] PCI: dwc: Add suspend_poweroff flag for platforms with RC power loss
Date: Tue, 4 Aug 2026 13:18:46 -0500 [thread overview]
Message-ID: <20260804181846.GA1846400@bhelgaas> (raw)
In-Reply-To: <GV2PR04MB12019D498722B4C8A94C2A1A28CD42@GV2PR04MB12019.eurprd04.prod.outlook.com>
On Tue, Aug 04, 2026 at 06:32:26AM +0000, Hongxing Zhu (OSS) wrote:
> > -----Original Message-----
> > From: Manivannan Sadhasivam <mani@kernel.org>
> > Sent: Monday, August 3, 2026 11:33 PM
> ...
> > On Thu, Jul 30, 2026 at 07:09:13AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Jul 30, 2026 at 08:16:36AM +0000, Hongxing Zhu (OSS) wrote:
> > > > > -----Original Message-----
> > > > > From: Bjorn Helgaas <helgaas@kernel.org>
> > > > > Sent: Thursday, July 30, 2026 6:30 AM
> > > > ...
> > >
> > > > > On Fri, Jul 17, 2026 at 03:41:21PM +0800, hongxing.zhu@oss.nxp.com
> > wrote:
> > > > > > From: Richard Zhu <hongxing.zhu@nxp.com>
> > > > > >
> > > > > > Some platforms like i.MX power off their PCIe RC
> > > > > > controllers during system suspend, requiring full
> > > > > > re-initialization on resume. These platforms need to enter
> > > > > > L2 state to properly notify endpoints before power loss.
> > > > > >
> > > > > > According to PCIe base spec r7.0, sec 5.2, the system
> > > > > > software should transition the device into D3Hot before
> > > > > > broadcasting the PME_Turn_Off message to initiate L2
> > > > > > entry. However, some endpoint devices fail the D3cold
> > > > > > capability check in pci_host_common_d3cold_possible(),
> > > > > > which would normally prevent L2 entry.
> > > > >
> > > > > Wakeup devices that don't support PME from D3cold will fail
> > > > > the D3cold capability check, but I don't think those are the
> > > > > problem you're solving.
> > > > >
> > > > You're right.
> > > >
> > > > > This appears to handle devices that are not in D3hot, and
> > > > > that's not a property of the endpoint; it's a property of
> > > > > its driver. Is the problem here that some driver didn't put
> > > > > its device in D3hot?
> > > > >
> > > > I observed some endpoint devices failing the D3cold capability
> > > > check, but I haven't identified the root cause.
> > >
> > > Seems like some instrumentation in
> > > pci_host_common_d3cold_possible() could tell us which
> > > devices/drivers are relevant.
> > >
> > > > > > For platforms where the RC loses power during suspend, L2
> > > > > > entry is essential regardless of D3cold support, as the
> > > > > > link will be lost anyway. Add a suspend_poweroff flag to
> > > > > > force L2 entry in such cases, and enable it for i.MX PCIe
> > > > > > controllers.
> > > > > >
> > > > > > Note: This violates the spec requirement that devices be
> > > > > > in D3Hot before PME_Turn_Off, but is necessary for proper
> > > > > > operation on platforms with RC power loss during suspend.
> > > > >
> > > > > If the device isn't in D3hot, it may still be active, and I
> > > > > think the PME_Turn_Off will abort any DMAs in progress,
> > > > > which doesn't sound like proper operation of the endpoint.
> > > >
> > > > You're correct - this isn't ideal for endpoint operation.
> > > > However, on i.MX platforms, the RC controller will lose power
> > > > during system suspend regardless. Without sending
> > > > PME_Turn_Off, endpoints would have no notification before the
> > > > link abruptly goes down.
> > >
> > > The PME_Turn_Off is some notification, but I don't think the
> > > endpoint can do DMA or MSI, so its driver won't be involved. It
> > > may be able to do things internally, e.g., write caches to an
> > > SSD or transmit packets from its internal buffers. But I think
> > > it might still lose power in the middle of operations like that,
> > > so it doesn't sound reliable.
> > >
> > > > This patch adds a flag to force L2 entry for such platforms,
> > > > choosing to notify endpoints (even if not ideal) rather than
> > > > having the link drop unexpectedly. I'm appreciated for
> > > > suggestions if there's a better approach to handle this
> > > > scenario.
> > >
> > > Mani recently added pci_suspend_retains_context(), and I think
> > > it returns "true" on i.MX. But if the RC is powered off and all
> > > the devices need full re-initialization on resume, it sounds
> > > like it *should* return "false".
> >
> > Right. pci_suspend_retains_context() was added just for that
> > purpose of telling client drivers to prepare for context loss. So
> > if this API returns 'false', then they should not hold the device
> > in D0.
>
> Thanks for your comments.
>
> If I update dw_pcie_suspend_noirq() to use
> pci_suspend_retains_context() to determine whether to proceed with
> L2 entry and RC power down. The new logic would be changed as below:
I'm not suggesting using pci_suspend_retains_context() in
dw_pcie_suspend_noirq(). pci_suspend_retains_context() is for
endpoint drivers.
I think pci_suspend_retains_context() should return 'false' on any
platform where dw_pcie_suspend_noirq() is going to send PME_Turn_Off.
Sending PME_Turn_Off means we intend to remove main power. When main
power is removed, devices will be in D3cold and they will not retain
their internal context.
If pci_suspend_retains_context() returns 'false' and
pci_host_common_d3cold_possible() returns also returns 'false', it
means some driver didn't put its device in D3hot when it should have.
In that case, I think you should either fix that driver so it *does*
put the device in D3hot (based on pci_suspend_retains_context()), or
just accept that you can't power off the RC.
next prev parent reply other threads:[~2026-08-04 18:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 7:41 [PATCH v2] PCI: dwc: Add suspend_poweroff flag for platforms with RC power loss hongxing.zhu
2026-07-17 7:46 ` sashiko-bot
2026-07-29 16:17 ` Manivannan Sadhasivam
2026-07-29 22:29 ` Bjorn Helgaas
2026-07-30 8:16 ` Hongxing Zhu (OSS)
2026-07-30 12:09 ` Bjorn Helgaas
2026-08-03 15:33 ` Manivannan Sadhasivam
2026-08-04 6:32 ` Hongxing Zhu (OSS)
2026-08-04 18:18 ` Bjorn Helgaas [this message]
2026-08-05 2:07 ` Hongxing Zhu (OSS)
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=20260804181846.GA1846400@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=festevam@gmail.com \
--cc=frank.li@nxp.com \
--cc=hongxing.zhu@nxp.com \
--cc=hongxing.zhu@oss.nxp.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=kwilczynski@kernel.org \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox