[PATCH v2] PCI: dwc: Add suspend_poweroff flag for platforms with RC power loss

[Bjorn Helgaas]

On Wed, Sep 16, 2026 at 04:00:24AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas at kernel.org>
> > Sent: Thursday, July 30, 2026 6:30 AM
> > To: Hongxing Zhu (OSS) <hongxing.zhu at oss.nxp.com>
> > Cc: Frank Li <frank.li at nxp.com>; l.stach at pengutronix.de;
> > lpieralisi at kernel.org; kwilczynski at kernel.org; mani at kernel.org;
> > robh at kernel.org; bhelgaas at google.com; s.hauer at pengutronix.de;
> > kernel at pengutronix.de; festevam at gmail.com; linux-pci at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org; imx at lists.linux.dev; linux-
> > kernel at vger.kernel.org; Hongxing Zhu <hongxing.zhu at nxp.com>
> > Subject: Re: [PATCH v2] PCI: dwc: Add suspend_poweroff flag for platforms
> > with RC power loss
> > 
> > On Fri, Jul 17, 2026 at 03:41:21PM +0800, hongxing.zhu at oss.nxp.com wrote:
> > > From: Richard Zhu <hongxing.zhu at 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.
> > 
> > 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?
> > 
> > > 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.
> 
> I apologize for not addressing your concerns promptly. Let me
> clarify the issue after reviewing this more carefully.
> 
> The problem I'm addressing:
> 
> L2 entry is being blocked for wakeup-capable devices that fail the
> D3cold capability check in `pci_host_common_d3cold_possible()`, even
> when the device is already in D3hot state.
> 
> Specifically:
> - The endpoint device is in D3hot (the driver has done its job correctly)
> - However, because it's a wakeup device that doesn't support PME from D3cold,
>   it fails the D3cold capability check
> - This failure currently prevents L2 entry, even though the device is already
>   in the required D3hot state as per the spec
> - For platforms like i.MX that power off the RC during suspend, we need L2
>   entry to properly notify the endpoint before power loss and complete
>   reinitialization successfully on resume.
> 
> So, the issue isn't about forcing devices into D3hot or handling
> devices that aren't in D3hot - it's about allowing L2 entry for
> devices that are already in D3hot but happen to fail the D3cold
> capability check due to wakeup requirements.
> 
> Regarding your concern about the commit message:
> 
> > "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 right. The commit message note about "violating the spec
> requirement" is misleading and incorrect. The endpoint device is in
> D3hot (the driver has done its job correctly), so it's compliant
> with the spec requirement. I should remove or reword that note in
> the next version.
> 
> Would you mind if I resubmitted the patch and used clearer
> submission information to accurately describe this situation?

Of course not, please do!

Bjorn