linux-kernel - Re: [PATCH v4 9/9] PCI: dwc: support missing PCIe device on resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <qlil44i7ywwxurdfovkbqvvjff7dey53uy5hzq4zbmvg7jg54o@zdg27w4q26gr>
Date: Sat, 1 Nov 2025 19:50:58 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
Cc: Sebastian Reichel <sebastian.reichel@...labora.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

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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்