linux-kernel - Re: [PATCH v4 3/6] PCI: dwc: Rework the error print of dw_pcie_wait_for

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6662785c-7912-4e58-a5b2-613ddac419c0@rock-chips.com>
Date: Wed, 7 Jan 2026 17:28:07 +0800
From: Shawn Lin <shawn.lin@...k-chips.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: shawn.lin@...k-chips.com, manivannan.sadhasivam@....qualcomm.com,
 Jingoo Han <jingoohan1@...il.com>, Lorenzo Pieralisi
 <lpieralisi@...nel.org>, Krzysztof Wilczyński
 <kwilczynski@...nel.org>, Rob Herring <robh@...nel.org>,
 Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, vincent.guittot@...aro.org,
 zhangsenchuan@...incomputing.com, Richard Zhu <hongxing.zhu@....com>
Subject: Re: [PATCH v4 3/6] PCI: dwc: Rework the error print of
 dw_pcie_wait_for_link()

在 2026/01/07 星期三 17:09, Manivannan Sadhasivam 写道:
> On Wed, Jan 07, 2026 at 04:38:14PM +0800, Shawn Lin wrote:
>> 在 2026/01/07 星期三 16:11, Manivannan Sadhasivam via B4 Relay 写道:
>>> From: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
>>>
>>> If the link fails to come up even after detecting the device on the bus
>>> i.e., if the LTSSM is not in Detect.Quiet and Detect.Active states, then
>>> dw_pcie_wait_for_link() should log it as an error.
>>>
>>> So promote dev_info() to dev_err(), reword the error log to make it clear
>>> and also print the LTSSM state to aid debugging.
>>
>> LTSSM might still be changing, so not sure how much value it would be
>> to print it at a singal moment, but anyway
>>
> 
> It is very unlikely that the LTSSM would be changing after the 1s timeout.
> Printing the state will allow debugging the link up failure.
> 

Most cases, yes. But I saw some reports that the LTSSM is stiling
changing between RCVRY_* and CFG_* when supporting customers. Especially
a buggy card I remembered, which sends some hot reset immediately after
link comes up. If it misses the first 1s wait for link check, then we
could see ltssm changing here. But better than nothing, keeps a log here
isn't a big deal I think. :)


> - Mani
> 
>> Reviewed-by: Shawn Lin <shawn.lin@...k-chips.com>
>>
>>>
>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
>>> ---
>>>    drivers/pci/controller/dwc/pcie-designware.c | 3 ++-
>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
>>> index 87f2ebc134d6..c2dfadc53d04 100644
>>> --- a/drivers/pci/controller/dwc/pcie-designware.c
>>> +++ b/drivers/pci/controller/dwc/pcie-designware.c
>>> @@ -776,7 +776,8 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
>>>    			return -ENODEV;
>>>    		}
>>> -		dev_info(pci->dev, "Phy link never came up\n");
>>> +		dev_err(pci->dev, "Link failed to come up. LTSSM: %s\n",
>>> +			dw_pcie_ltssm_status_string(ltssm));
>>>    		return -ETIMEDOUT;
>>>    	}
>>>
>>
>