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:19 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 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.