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] [day] [month] [year] [list]
Message-ID:
 <AS8PR04MB8676595EA27CA466031D9DFB8C3D2@AS8PR04MB8676.eurprd04.prod.outlook.com>
Date: Tue, 10 Dec 2024 02:31:52 +0000
From: Hongxing Zhu <hongxing.zhu@....com>
To: Damien Le Moal <dlemoal@...nel.org>, "jingoohan1@...il.com"
	<jingoohan1@...il.com>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"lpieralisi@...nel.org" <lpieralisi@...nel.org>, "kw@...ux.com"
	<kw@...ux.com>, "manivannan.sadhasivam@...aro.org"
	<manivannan.sadhasivam@...aro.org>, "robh@...nel.org" <robh@...nel.org>,
	Frank Li <frank.li@....com>, "quic_krichai@...cinc.com"
	<quic_krichai@...cinc.com>
CC: "imx@...ts.linux.dev" <imx@...ts.linux.dev>, "kernel@...gutronix.de"
	<kernel@...gutronix.de>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 1/3] PCI: dwc: Fix resume failure if no EP is connected
 on some platforms




Best Regards
Richard Zhu

> -----Original Message-----
> From: Damien Le Moal <dlemoal@...nel.org>
> Sent: 2024年12月9日 16:50
> To: Hongxing Zhu <hongxing.zhu@....com>; jingoohan1@...il.com;
> bhelgaas@...gle.com; lpieralisi@...nel.org; kw@...ux.com;
> manivannan.sadhasivam@...aro.org; robh@...nel.org; Frank Li
> <frank.li@....com>; quic_krichai@...cinc.com
> Cc: imx@...ts.linux.dev; kernel@...gutronix.de; linux-pci@...r.kernel.org;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v3 1/3] PCI: dwc: Fix resume failure if no EP is connected on
> some platforms
> 
> On 12/9/24 16:39, Richard Zhu wrote:
> > The dw_pcie_suspend_noirq() function currently returns success
> > directly if no endpoint (EP) device is connected. However, on some
> > platforms, power loss occurs during suspend, causing dw_resume() to do
> > nothing in this case. This results in a system halt because the DWC
> > controller is not initialized after power-on during resume.
> >
> > Call deinit() in suspend and init() at resume regardless of whether
> > there are EP device connections or not. It is not harmful to perform
> > deinit() and init() again for the no power-off case, and it keeps the
> > code simple and consistent in logic.
> >
> > Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume
> > functionality")
> > Signed-off-by: Richard Zhu <hongxing.zhu@....com>
> > Reviewed-by: Frank Li <Frank.Li@....com>
> > ---
> >  .../pci/controller/dwc/pcie-designware-host.c | 30
> > +++++++++----------
> >  1 file changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > index f882b11fd7b94..11563402c571b 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > @@ -982,23 +982,23 @@ int dw_pcie_suspend_noirq(struct dw_pcie *pci)
> >  	if (dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKCTL) &
> PCI_EXP_LNKCTL_ASPM_L1)
> >  		return 0;
> >
> > -	if (dw_pcie_get_ltssm(pci) <= DW_PCIE_LTSSM_DETECT_ACT)
> > -		return 0;
> > -
> > -	if (pci->pp.ops->pme_turn_off)
> > -		pci->pp.ops->pme_turn_off(&pci->pp);
> > -	else
> > -		ret = dw_pcie_pme_turn_off(pci);
> > +	/* Only send out PME_TURN_OFF when PCIE link is up */
> > +	if (dw_pcie_get_ltssm(pci) > DW_PCIE_LTSSM_DETECT_ACT) {
> > +		if (pci->pp.ops->pme_turn_off)
> > +			pci->pp.ops->pme_turn_off(&pci->pp);
> > +		else
> > +			ret = dw_pcie_pme_turn_off(pci);
> >
> > -	if (ret)
> > -		return ret;
> > +		if (ret)
> > +			return ret;
> 
> Same comment as for patch 3. This "if (ret) return ret;" can go inside the else.
> It is harmless, but there is also no point in having it here.
> 
Hi Damien:
Okay, thanks.
BTW, I'm considering that the use-case of #1 patch had been covered by #3
 commit already.
Since, the PME_TURN_OFF would be kicked off without LTSSM stat check in #3.
To be simple, how about drop the #1 patch, re-format the codes, and add one
 Fixes tag into #3?

Best Regards
Richard Zhu
> >
> > -	ret = read_poll_timeout(dw_pcie_get_ltssm, val, val ==
> DW_PCIE_LTSSM_L2_IDLE,
> > -				PCIE_PME_TO_L2_TIMEOUT_US/10,
> > -				PCIE_PME_TO_L2_TIMEOUT_US, false, pci);
> > -	if (ret) {
> > -		dev_err(pci->dev, "Timeout waiting for L2 entry! LTSSM: 0x%x\n", val);
> > -		return ret;
> > +		ret = read_poll_timeout(dw_pcie_get_ltssm, val, val ==
> DW_PCIE_LTSSM_L2_IDLE,
> > +					PCIE_PME_TO_L2_TIMEOUT_US/10,
> > +					PCIE_PME_TO_L2_TIMEOUT_US, false, pci);
> > +		if (ret) {
> > +			dev_err(pci->dev, "Timeout waiting for L2 entry! LTSSM: 0x%x\n",
> val);
> > +			return ret;
> > +		}
> >  	}
> >
> >  	if (pci->pp.ops->deinit)
> 
> 
> --
> Damien Le Moal
> Western Digital Research

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ