[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <s67opnadijrebativ27oiofub5cgr3lbclhxnmwnqrkltweqqj@j4douhswobsv>
Date: Mon, 3 Nov 2025 20:00:45 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof WilczyĆski <kwilczynski@...nel.org>, 
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Heiko Stuebner <heiko@...ech.de>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Jingoo Han <jingoohan1@...il.com>, Shawn Lin <shawn.lin@...k-chips.com>, linux-pci@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	kernel@...labora.com
Subject: Re: [PATCH v4 9/9] PCI: dwc: support missing PCIe device on resume
Hi,
On Sat, Nov 01, 2025 at 07:50:58PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Oct 30, 2025 at 11:07:19AM +0530, Krishna Chaitanya Chundru wrote:
> > 
> > On 10/29/2025 11:26 PM, Sebastian Reichel wrote:
> > > When dw_pcie_resume_noirq() is called for a PCIe root complex for a PCIe
> > > slot with no device plugged on Rockchip RK3576, dw_pcie_wait_for_link()
> > > will return -ETIMEDOUT. During probe time this does not happen, since
> > > the platform sets 'use_linkup_irq'.
> > > 
> > > This adds the same logic from dw_pcie_host_init() to the PM resume
> > > function to avoid the problem.
> > > 
> > > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> > > ---
> > >   drivers/pci/controller/dwc/pcie-designware-host.c | 13 ++++++++++---
> > >   1 file changed, 10 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index e92513c5bda5..f25f1c136900 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -1215,9 +1215,16 @@ int dw_pcie_resume_noirq(struct dw_pcie *pci)
> > >   	if (ret)
> > >   		return ret;
> > > -	ret = dw_pcie_wait_for_link(pci);
> > > -	if (ret)
> > > -		return ret;
> > > +	/*
> > > +	 * Note: Skip the link up delay only when a Link Up IRQ is present.
> > > +	 * If there is no Link Up IRQ, we should not bypass the delay
> > > +	 * because that would require users to manually rescan for devices.
> > > +	 */
> > 
> > In the resume scenario, we should explicitly wait for the link to be up,
> > there is no IRQ support at this resume phase
> 
> This could be fixed if the PM handlers are moved to non-no_irq ones.
> 
> > and secondly after controller resume pm framework will start resuming the
> > bridges & endpoints. what happens
> > if the link is not up by the time endpoint is resume is called. And entire
> > save & restore states might also gets messed up.
> > There will be no way to recover from this.
> > 
> 
> This is true if there were any devices connected to the bus during suspend. If
> there were no devices, then it is fine to skip waiting for the link to be up.
I thought about setting a flag in the suspend routine, that a device
is expected to be there at resume time. But I suppose it might also
have been removed during the system suspend?
Greetings,
-- Sebastian
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists