linux-kernel - Re: [PATCH v3 0/4] PCI: dwc: Rework the error handling 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b7d7ae6b-d0e7-47f2-ac84-8b0fdb395a59@rock-chips.com>
Date: Wed, 21 Jan 2026 20:45:39 +0800
From: Shawn Lin <shawn.lin@...k-chips.com>
To: Niklas Cassel <cassel@...nel.org>
Cc: shawn.lin@...k-chips.com, Jingoo Han <jingoohan1@...il.com>,
 Manivannan Sadhasivam <mani@...nel.org>,
 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,
 dlemoal@...nel.org, manivannan.sadhasivam@....qualcomm.com
Subject: Re: [PATCH v3 0/4] PCI: dwc: Rework the error handling of
 dw_pcie_wait_for_link() API


在 2026/01/02 星期五 20:01, Niklas Cassel 写道:
> On Tue, Dec 30, 2025 at 08:37:31PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>> Hi,
>>
>> This series reworks the dw_pcie_wait_for_link() API to allow the callers to
>> detect the absence of the device on the bus and skip the failure.
>>
>> Compared to v2, I've reworked the patch 2 to improve the API further and
>> dropped the patch 1 that got applied (hence changed the subject). I've also
>> modified the error code based on the feedback in v2 to return -ENODEV if device
>> is not detected on the bus and -ETIMEDOUT otherwise. This allows the callers to
>> skip the failure if device is not detected and handle error for other failure.
>>
>> Testing
>> =======
>>
>> Tested this series on Rb3Gen2 board without powering on the PCIe switch. Now the
>> dw_pcie_wait_for_link() API prints:
>>
>> 	qcom-pcie 1c08000.pcie: Device not found
>>
>> Instead of the previous log:
>>
>> 	qcom-pcie 1c08000.pcie: Phy link never came up
> 
> Hello Mani,
> 
> I really like this series.
> 
> However when testing my usual setup with 2 Rock 5B:s, one in EP mode, one
> in RC mode, where I usually power on both boards at the same time, but only
> after both boards are booted, do I do the configfs write to enable the link
> training on EP, and then do a rescan on the RC.
> 
> Even with this series, this workflow still works in 8 out of 10 boots.
> 
> 
> However, in 2 out of 10 boots I instead got:
> [    2.285827] rockchip-dw-pcie a40000000.pcie: Link failed to come up. LTSSM: POLL_COMPLIANCE
> [    2.286584] rockchip-dw-pcie a40000000.pcie: probe with driver rockchip-dw-pcie failed with error -110
> 
> In both cases LTSSM was in POLL_COMPLIANCE.
> 
> 
> Considering that things work in 8 out of 10 boots, means that the LTSSM state
> was in Detect.Quiet or Detect.Active.
> 
> I did comment out goto err_stop_link if dw_pcie_wait_for_link(), so I can dump
> LTSSM afterwards, when this happens.
> 
> [    2.293785] rockchip-dw-pcie a40000000.pcie: Link failed to come up. LTSSM: POLL_COMPLIANCE
> 
> Then I do:
> 
> # cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status
> POLL_COMPLIANCE (0x03)
> 
> So LTSSM is still in Poll.Compliance.
> 
> However, as soon as I do the configfs writes on the EP board:
> 
> 
> # cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status
> L0 (0x11)
> # cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status
> L0 (0x11)
> 
> LTSSM transitions out of compliance, and rescan will find my device:
> 
> # echo 1 > /sys/bus/pci/devices/0000:00:00.0/rescan
> [  246.777867] pci 0000:01:00.0: [1d87:3588] type 00 class 0xff0000 PCIe Endpoint
> [  246.778627] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x000fffff]
> [  246.779151] pci 0000:01:00.0: BAR 1 [mem 0x00000000-0x000fffff]
> [  246.779672] pci 0000:01:00.0: BAR 2 [mem 0x00000000-0x000fffff]
> [  246.780192] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x000fffff]
> [  246.780716] pci 0000:01:00.0: BAR 5 [mem 0x00000000-0x000fffff]
> [  246.781236] pci 0000:01:00.0: ROM [mem 0x00000000-0x0000ffff pref]
> 
> 
> 
> I understand that in most normal situations, the endpoint is powered on
> before powering on the host side (or there is no EP connected at all).
> But somehow, for us PCIe endpoint developers, it would be nice if we
> could keep the behavior of being able to rescan the bus, even when the EP
> is not powered on before the host side.
> 
> Perhaps a Kconfig or module param? Suggestions?
> 

Hi Niklas,

Sorry for chiming in on this so late. There is a register called
PCIE_CLIENT_GENERAL_DEBUG_CON you may find on RK3588 TRM, you could
hold LTSSM on EP side in DETECT_QUIET before enabling trainning, by
setting BIT(6). And when EP side is ready to go, just clear BIT(6),
so the link is able to be established and host side can rescan to
find the EP properly.
	


> 
> Kind regards,
> Niklas
>