[PATCH] PCI: dw-rockchip: Skip waiting for link up

[PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

The Root Complex specific device tree binding for pcie-dw-rockchip has the
'sys' interrupt marked as required.

The driver requests the 'sys' IRQ unconditionally, and errors out if not
provided.

Thus, we can unconditionally set use_linkup_irq before calling
dw_pcie_host_init().

This will skip the wait for link up (since the bus will be enumerated once
the link up IRQ is triggered), which reduces the bootup time.

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 1170e1107508bd793b610949b0afe98516c177a4..62034affb95fbb965aad3cebc613a83e31c90aee 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -435,6 +435,7 @@ static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
 
 	pp = &rockchip->pci.pp;
 	pp->ops = &rockchip_pcie_host_ops;
+	pp->use_linkup_irq = true;
 
 	return dw_pcie_host_init(pp);
 }

---
base-commit: 2adda4102931b152f35d054055497631ed97fe73
change-id: 20250113-rockchip-no-wait-403ffbc42313

Best regards,
-- 
Niklas Cassel <cassel@kernel.org>

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Bjorn Helgaas]

On Mon, Jan 13, 2025 at 11:59:34AM +0100, Niklas Cassel wrote:
> The Root Complex specific device tree binding for pcie-dw-rockchip has the
> 'sys' interrupt marked as required.
> 
> The driver requests the 'sys' IRQ unconditionally, and errors out if not
> provided.
> 
> Thus, we can unconditionally set use_linkup_irq before calling
> dw_pcie_host_init().
> 
> This will skip the wait for link up (since the bus will be enumerated once
> the link up IRQ is triggered), which reduces the bootup time.
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>

Thanks!  I was just reviewing the addition of your dll_link_up IRQ
handler, and was about to ask whether you wanted to set use_linkup_irq
to avoid the wait, but here's the patch already :)

I think I'll sort out the branches so the dll_link_up IRQ handler,
this patch, and the corresponding qcom change go on the same branch as
Krishna's patch to skip waiting if pp->use_linkup_irq.

> ---
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 1170e1107508bd793b610949b0afe98516c177a4..62034affb95fbb965aad3cebc613a83e31c90aee 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -435,6 +435,7 @@ static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
>  
>  	pp = &rockchip->pci.pp;
>  	pp->ops = &rockchip_pcie_host_ops;
> +	pp->use_linkup_irq = true;
>  
>  	return dw_pcie_host_init(pp);
>  }
> 
> ---
> base-commit: 2adda4102931b152f35d054055497631ed97fe73
> change-id: 20250113-rockchip-no-wait-403ffbc42313
> 
> Best regards,
> -- 
> Niklas Cassel <cassel@kernel.org>
> 

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On 13 January 2025 20:27:20 CET, Bjorn Helgaas <helgaas@kernel.org> wrote:
>On Mon, Jan 13, 2025 at 11:59:34AM +0100, Niklas Cassel wrote:
>> The Root Complex specific device tree binding for pcie-dw-rockchip has the
>> 'sys' interrupt marked as required.
>> 
>> The driver requests the 'sys' IRQ unconditionally, and errors out if not
>> provided.
>> 
>> Thus, we can unconditionally set use_linkup_irq before calling
>> dw_pcie_host_init().
>> 
>> This will skip the wait for link up (since the bus will be enumerated once
>> the link up IRQ is triggered), which reduces the bootup time.
>> 
>> Signed-off-by: Niklas Cassel <cassel@kernel.org>
>
>Thanks!  I was just reviewing the addition of your dll_link_up IRQ
>handler, and was about to ask whether you wanted to set use_linkup_irq
>to avoid the wait, but here's the patch already :)

:)

>
>I think I'll sort out the branches so the dll_link_up IRQ handler,
>this patch, and the corresponding qcom change go on the same branch as
>Krishna's patch to skip waiting if pp->use_linkup_irq.

That sounds like a good idea.

Thank you!


Kind regards,
Niklas

>
>> ---
>>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> index 1170e1107508bd793b610949b0afe98516c177a4..62034affb95fbb965aad3cebc613a83e31c90aee 100644
>> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> @@ -435,6 +435,7 @@ static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
>>  
>>  	pp = &rockchip->pci.pp;
>>  	pp->ops = &rockchip_pcie_host_ops;
>> +	pp->use_linkup_irq = true;
>>  
>>  	return dw_pcie_host_init(pp);
>>  }
>> 
>> ---
>> base-commit: 2adda4102931b152f35d054055497631ed97fe73
>> change-id: 20250113-rockchip-no-wait-403ffbc42313
>> 
>> Best regards,
>> -- 
>> Niklas Cassel <cassel@kernel.org>
>> 

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Bjorn Helgaas]

On Mon, Jan 13, 2025 at 11:59:34AM +0100, Niklas Cassel wrote:
> The Root Complex specific device tree binding for pcie-dw-rockchip has the
> 'sys' interrupt marked as required.
> 
> The driver requests the 'sys' IRQ unconditionally, and errors out if not
> provided.
> 
> Thus, we can unconditionally set use_linkup_irq before calling
> dw_pcie_host_init().
> 
> This will skip the wait for link up (since the bus will be enumerated once
> the link up IRQ is triggered), which reduces the bootup time.
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>

Applied to pci/controller/dwc for v6.14, thanks!

> ---
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 1170e1107508bd793b610949b0afe98516c177a4..62034affb95fbb965aad3cebc613a83e31c90aee 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -435,6 +435,7 @@ static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
>  
>  	pp = &rockchip->pci.pp;
>  	pp->ops = &rockchip_pcie_host_ops;
> +	pp->use_linkup_irq = true;
>  
>  	return dw_pcie_host_init(pp);
>  }
> 
> ---
> base-commit: 2adda4102931b152f35d054055497631ed97fe73
> change-id: 20250113-rockchip-no-wait-403ffbc42313
> 
> Best regards,
> -- 
> Niklas Cassel <cassel@kernel.org>
> 

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Niklas, Bjorn,

I noticed an issue on the Rockchip RK3588S SoC using the ASMedia ASM2806 
PCIe bridge where devices behind the bridge fail to probe since v6.14.
Specifically, this started happening after commit 
647d69605c70368d54fc012fce8a43e8e5955b04.
dmesg logs from before and after this commit are available at:
  https://gist.github.com/RadxaNaoki/fca2bfca2ee80fefee7b00c7967d2e3d

I have confirmed that reverting the following commits fixes the issue:
  commit ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we 
can detect Link Up")
  commit 0e0b45ab5d77 ("PCI: dw-rockchip: Enumerate endpoints based on 
dll_link_up IRQ")

On v6.18-rc2, the cold boot behavior has changed somewhat, and I have 
observed the following three behaviors so far:

- Probe succeeds
- Probe fails
- Kernel oops

There seems to be no pattern to these three behaviors. During a warm 
boot, a successful probe does not seem to occur.

If commit ec9fd499b9c6 is reverted on v6.18-rc2, I have observed the 
following two behaviors so far:

- Probe succeeds
- Kernel oops

"Probe fails" has not been observed so far.

The dmesg for the kernel oops is available at:
  https://gist.github.com/RadxaNaoki/4b2dcd5e41b09004eda2fdeb80ae5e15

Can you please help me with this issue?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 1/13/25 19:59, Niklas Cassel wrote:
> The Root Complex specific device tree binding for pcie-dw-rockchip has the
> 'sys' interrupt marked as required.
> 
> The driver requests the 'sys' IRQ unconditionally, and errors out if not
> provided.
> 
> Thus, we can unconditionally set use_linkup_irq before calling
> dw_pcie_host_init().
> 
> This will skip the wait for link up (since the bus will be enumerated once
> the link up IRQ is triggered), which reduces the bootup time.
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>   drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> 
> ---
> base-commit: 2adda4102931b152f35d054055497631ed97fe73
> change-id: 20250113-rockchip-no-wait-403ffbc42313
> 
> Best regards,
> 
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 1170e1107508bd793b610949b0afe98516c177a4..62034affb95fbb965aad3cebc613a83e31c90aee 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -435,6 +435,7 @@ static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
>   
>   	pp = &rockchip->pci.pp;
>   	pp->ops = &rockchip_pcie_host_ops;
> +	pp->use_linkup_irq = true;
>   
>   	return dw_pcie_host_init(pp);
>   }

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Shawn Lin]

在 2025/10/21 星期二 12:26, FUKAUMI Naoki 写道:
> Hi Niklas, Bjorn,
> 
> I noticed an issue on the Rockchip RK3588S SoC using the ASMedia ASM2806 
> PCIe bridge where devices behind the bridge fail to probe since v6.14.
> Specifically, this started happening after commit 
> 647d69605c70368d54fc012fce8a43e8e5955b04.
> dmesg logs from before and after this commit are available at:
>   https://gist.github.com/RadxaNaoki/fca2bfca2ee80fefee7b00c7967d2e3d
> 
> I have confirmed that reverting the following commits fixes the issue:
>   commit ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we 
> can detect Link Up")
>   commit 0e0b45ab5d77 ("PCI: dw-rockchip: Enumerate endpoints based on 
> dll_link_up IRQ")
> 

Then these two commits would like to reply on link up irq instead of
fixed delay in dwc framework. Here is a not very precise timeline
description.

time(ms) |  dw_pcie_wait_for_link（）     | sys irq_thread() | Hot reset
-------------------------------------------------------------------------
0:       |  dw_pcie_link_up return false  |  link up irq     |
1x       |  Physical link up happend      |                  |
90:      |  dw_pcie_link_up return true   |                  |
100:     |                                |  msleep(100) done|
10x:     |                                |  pci_rescan_bus  |
1xx:     |                                |                  | <==occur
190:     |  msleep(90) done               |                  |
19x:     |  pci_host_probe                |                  |

What if the hot reset happens when pci_rescan_bus() starts. I think
scan devices possible fail when seeing 0xffffffff from cfg read. But
a 90ms delay perfectly avoids this event in dw_pcie_wait_for_link(), and 
by the time the 90ms delay is completed, the link is actually in an
accessible state.

> On v6.18-rc2, the cold boot behavior has changed somewhat, and I have 
> observed the following three behaviors so far:
> 
> - Probe succeeds
> - Probe fails
> - Kernel oops
> 
> There seems to be no pattern to these three behaviors. During a warm 
> boot, a successful probe does not seem to occur.
> 
> If commit ec9fd499b9c6 is reverted on v6.18-rc2, I have observed the 
> following two behaviors so far:
> 
> - Probe succeeds
> - Kernel oops
> 
> "Probe fails" has not been observed so far.
> 
> The dmesg for the kernel oops is available at:
>   https://gist.github.com/RadxaNaoki/4b2dcd5e41b09004eda2fdeb80ae5e15
> 
> Can you please help me with this issue?
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
> On 1/13/25 19:59, Niklas Cassel wrote:
>> The Root Complex specific device tree binding for pcie-dw-rockchip has 
>> the
>> 'sys' interrupt marked as required.
>>
>> The driver requests the 'sys' IRQ unconditionally, and errors out if not
>> provided.
>>
>> Thus, we can unconditionally set use_linkup_irq before calling
>> dw_pcie_host_init().
>>
>> This will skip the wait for link up (since the bus will be enumerated 
>> once
>> the link up IRQ is triggered), which reduces the bootup time.
>>
>> Signed-off-by: Niklas Cassel <cassel@kernel.org>
>> ---
>>   drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>>
>> ---
>> base-commit: 2adda4102931b152f35d054055497631ed97fe73
>> change-id: 20250113-rockchip-no-wait-403ffbc42313
>>
>> Best regards,
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/ 
>> pci/controller/dwc/pcie-dw-rockchip.c
>> index 
>> 1170e1107508bd793b610949b0afe98516c177a4..62034affb95fbb965aad3cebc613a83e31c90aee 100644
>> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> @@ -435,6 +435,7 @@ static int rockchip_pcie_configure_rc(struct 
>> rockchip_pcie *rockchip)
>>       pp = &rockchip->pci.pp;
>>       pp->ops = &rockchip_pcie_host_ops;
>> +    pp->use_linkup_irq = true;
>>       return dw_pcie_host_init(pp);
>>   }
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

Hello Shawn,

On Tue, Oct 21, 2025 at 03:10:13PM +0800, Shawn Lin wrote:
> 在 2025/10/21 星期二 12:26, FUKAUMI Naoki 写道:
> > Hi Niklas, Bjorn,
> > 
> > I noticed an issue on the Rockchip RK3588S SoC using the ASMedia ASM2806
> > PCIe bridge where devices behind the bridge fail to probe since v6.14.
> > Specifically, this started happening after commit
> > 647d69605c70368d54fc012fce8a43e8e5955b04.
> > dmesg logs from before and after this commit are available at:
> >   https://gist.github.com/RadxaNaoki/fca2bfca2ee80fefee7b00c7967d2e3d
> > 
> > I have confirmed that reverting the following commits fixes the issue:
> >   commit ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we
> > can detect Link Up")
> >   commit 0e0b45ab5d77 ("PCI: dw-rockchip: Enumerate endpoints based on
> > dll_link_up IRQ")
> > 
> 
> Then these two commits would like to reply on link up irq instead of
> fixed delay in dwc framework. Here is a not very precise timeline
> description.
> 
> time(ms) |  dw_pcie_wait_for_link（）     | sys irq_thread() | Hot reset
> -------------------------------------------------------------------------
> 0:       |  dw_pcie_link_up return false  |  link up irq     |
> 1x       |  Physical link up happend      |                  |
> 90:      |  dw_pcie_link_up return true   |                  |
> 100:     |                                |  msleep(100) done|
> 10x:     |                                |  pci_rescan_bus  |
> 1xx:     |                                |                  | <==occur
> 190:     |  msleep(90) done               |                  |
> 19x:     |  pci_host_probe                |                  |
> 
> What if the hot reset happens when pci_rescan_bus() starts. I think
> scan devices possible fail when seeing 0xffffffff from cfg read. But
> a 90ms delay perfectly avoids this event in dw_pcie_wait_for_link(), and by
> the time the 90ms delay is completed, the link is actually in an
> accessible state.

The pcie-dw-rockchip.c driver is modelled after the qcom driver.
So if this is a problem when a ASM2806 switch is connected, I would
expect qcom platforms to have the same problem.


Do we have a PCI trace that can tell us exactly what goes wrong?

FUKAUMI-san tells us that the enumeration does not detect any devices,
but also that there is no crash.

If we assume the scenario from your timeline above, that a hot reset
happens just after pci_rescan_bus(), after a hot reset, LTSSM should
re-enter link training.

I verified this:
# bc=$(setpci -s 0000:00:00.0 BRIDGE_CONTROL)
# setpci -s 0000:00:00.0 BRIDGE_CONTROL=$(printf "%04x" $((0x$bc | 0x40))) && sl eep 0.01 && setpci -s 0000:00:00.0 BRIDGE_CONTROL=$bc
[   65.723990] rockchip-dw-pcie a40000000.pcie: PCIE_CLIENT_INTR_STATUS_MISC: 0x7
[   65.724701] rockchip-dw-pcie a40000000.pcie: LTSSM_STATUS: 0x30011
[   65.825787] rockchip-dw-pcie a40000000.pcie: Received Link up event. Starting enumeration!

So we get another link up IRQ after the hot reset.

The IRQ handler for this IRQ will once again call pci_rescan_bus().
So I would expect that this second pci_rescan_bus() call would actually
be able to find the device behind the switch.


Mani, Bjorn, thoughts?



Kind regards,
Niklas

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On Sat, Nov 08, 2025 at 01:34:32PM +0100, Niklas Cassel wrote:
> 
> The pcie-dw-rockchip.c driver is modelled after the qcom driver.
> So if this is a problem when a ASM2806 switch is connected, I would
> expect qcom platforms to have the same problem.

Looking more closely at this, comparing the "good" kernel:

[    1.868857] pci 0004:40:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port
[    1.869509] pci 0004:40:00.0: ROM [mem 0x00000000-0x0000ffff pref]
[    1.870050] pci 0004:40:00.0: PCI bridge to [bus 01-ff]
[    1.870510] pci 0004:40:00.0:   bridge window [io  0x0000-0x0fff]
[    1.871044] pci 0004:40:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.871640] pci 0004:40:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[    1.872353] pci 0004:40:00.0: supports D1 D2
[    1.872738] pci 0004:40:00.0: PME# supported from D0 D1 D3hot
[    1.875190] pci 0004:40:00.0: Primary bus is hard wired to 0
[    1.875690] pci 0004:40:00.0: bridge configuration invalid ([bus 01-ff]), reconfiguring
[    1.876543] pci 0004:41:00.0: [1b21:2806] type 01 class 0x060400 PCIe Switch Upstream Port
[    1.877384] pci 0004:41:00.0: PCI bridge to [bus 00]
[    1.877846] pci 0004:41:00.0:   bridge window [io  0x0000-0x0fff]
[    1.878389] pci 0004:41:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.879030] pci 0004:41:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[    1.879764] pci 0004:41:00.0: enabling Extended Tags
[    1.880614] pci 0004:41:00.0: PME# supported from D0 D3hot D3cold
[    1.881409] pci 0004:41:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
[    1.888729] pci 0004:41:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    1.889766] pci 0004:42:00.0: [1b21:2806] type 01 class 0x060400 PCIe Switch Downstream Port
[    1.890621] pci 0004:42:00.0: PCI bridge to [bus 00]
[    1.891084] pci 0004:42:00.0:   bridge window [io  0x0000-0x0fff]
[    1.891628] pci 0004:42:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.892269] pci 0004:42:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[    1.893028] pci 0004:42:00.0: enabling Extended Tags
...
[    1.928510] pci_bus 0004:43: busn_res: [bus 43-4f] end is updated to 44
[    1.929432] pci_bus 0004:45: busn_res: [bus 45-4f] end is updated to 45
[    1.944674] pci_bus 0004:46: busn_res: [bus 46-4f] end is updated to 46
[    1.956691] pci_bus 0004:47: busn_res: [bus 47-4f] end is updated to 47
[    1.957298] pci_bus 0004:42: busn_res: [bus 42-4f] end is updated to 47
[    1.957893] pci_bus 0004:41: busn_res: [bus 41-4f] end is updated to 47


With the "bad" kernel:
[    1.383075] pci 0004:40:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port
[    1.383738] pci 0004:40:00.0: ROM [mem 0x00000000-0x0000ffff pref]
[    1.384280] pci 0004:40:00.0: PCI bridge to [bus 01-ff]
[    1.384740] pci 0004:40:00.0:   bridge window [io  0x0000-0x0fff]
[    1.385274] pci 0004:40:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.385871] pci 0004:40:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[    1.386582] pci 0004:40:00.0: supports D1 D2
[    1.386957] pci 0004:40:00.0: PME# supported from D0 D1 D3hot
[    1.389549] pci 0004:40:00.0: Primary bus is hard wired to 0
[    1.390062] pci 0004:40:00.0: bridge configuration invalid ([bus 01-ff]), reconfiguring
[    1.390897] pci_bus 0004:41: busn_res: [bus 41-4f] end is updated to 41
[    1.391505] pci 0004:40:00.0: ROM [mem 0xf4200000-0xf420ffff pref]: assigned
[    1.392130] pci 0004:40:00.0: PCI bridge to [bus 41]
[    1.392607] pci_bus 0004:40: resource 4 [io  0x0000-0xfffff]
[    1.393103] pci_bus 0004:40: resource 5 [mem 0xf4200000-0xf4ffffff]
[    1.393657] pci_bus 0004:40: resource 6 [mem 0xa00000000-0xa3fffffff]
[    1.412296] pci 0004:41:00.0: [1b21:2806] type 01 class 0x060400 PCIe Switch Upstream Port
[    1.413155] pci 0004:41:00.0: PCI bridge to [bus 00]
[    1.413641] pci 0004:41:00.0:   bridge window [io  0x0000-0x0fff]
[    1.414204] pci 0004:41:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.414934] pci 0004:41:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[    1.415746] pci 0004:41:00.0: enabling Extended Tags
[    1.416465] pci 0004:41:00.0: PME# supported from D0 D3hot D3cold
[    1.417181] pci 0004:41:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
[    1.423384] pci 0004:41:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    1.424348] pci_bus 0004:42: busn_res: can not insert [bus 42-41] under [bus 41] (conflicts with (null) [bus 41])
[    1.425351] pci 0004:42:00.0: [1b21:2806] type 01 class 0x060400 PCIe Switch Downstream Port
[    1.426698] pci 0004:42:00.0: PCI bridge to [bus 00]
[    1.427184] pci 0004:42:00.0:   bridge window [io  0x0000-0x0fff]
[    1.427766] pci 0004:42:00.0:   bridge window [mem 0x00000000-0x000fffff]
[    1.428415] pci 0004:42:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[    1.429171] pci 0004:42:00.0: enabling Extended Tags
...
[    1.462051] pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.463116] pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
[    1.463718] pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.464651] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
[    1.465688] pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.466747] pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
[    1.467351] pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.468283] pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
[    1.469322] pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.470370] pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
[    1.470960] pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.471902] pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
[    1.472930] pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.473985] pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
[    1.474578] pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.475530] pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
[    1.476414] pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
[    1.477001] pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
[    1.477911] pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
[    1.478814] pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46


We can see that the pcie-dw-rockchip.c driver detects the ASM2806 switch
in both cases. So the problem is not really with enumerating the root port.

The problem seems to be that with the "bad" kernel, you get a lot of:
[    1.464651] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them

Because the bus ends are different, and conflicts with each other.
I don't know why this happens.

Perhaps we could add a quirk for ASM2806 that does some extra sleep if that
switch is detected, if for some reason, the switch is not actually ready
after the delays defined by the PCIe specification.

(And btw. please test with the latest 6.18-rc, as, from experience, the
ASPM problems in earlier RCs can result in some weird problems that are
not immediately deduced to be caused by the ASPM enablement.)


Kind regards,
Niklas

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Diederik de Haas]

On Sat Nov 8, 2025 at 2:27 PM CET, Niklas Cassel wrote:
> On Sat, Nov 08, 2025 at 01:34:32PM +0100, Niklas Cassel wrote:
>> 
>> The pcie-dw-rockchip.c driver is modelled after the qcom driver.
>> So if this is a problem when a ASM2806 switch is connected, I would
>> expect qcom platforms to have the same problem.
>
> Looking more closely at this, comparing the "good" kernel:

There's another thing that caught my eye ...

> [    1.868857] pci 0004:40:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port
> [    1.869509] pci 0004:40:00.0: ROM [mem 0x00000000-0x0000ffff pref]
> ...
> [    1.879764] pci 0004:41:00.0: enabling Extended Tags
> [    1.880614] pci 0004:41:00.0: PME# supported from D0 D3hot D3cold
> [    1.881409] pci 0004:41:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)

... 2.000 Gb/s ...

> [    1.888729] pci 0004:41:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> ...
>
>
> With the "bad" kernel:
> [    1.383075] pci 0004:40:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port
> [    1.383738] pci 0004:40:00.0: ROM [mem 0x00000000-0x0000ffff pref]
> ...
> [    1.415746] pci 0004:41:00.0: enabling Extended Tags
> [    1.416465] pci 0004:41:00.0: PME# supported from D0 D3hot D3cold
> [    1.417181] pci 0004:41:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)

... 4.0000 Gb/s

I don't know if that's relevant or important, but wanted to mention it.

Cheers,
  Diederik

> [    1.423384] pci 0004:41:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> ...
>
>
> We can see that the pcie-dw-rockchip.c driver detects the ASM2806 switch
> in both cases. So the problem is not really with enumerating the root port.
>
> The problem seems to be that with the "bad" kernel, you get a lot of:
> [    1.464651] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
>
> Because the bus ends are different, and conflicts with each other.
> I don't know why this happens.
>
> Perhaps we could add a quirk for ASM2806 that does some extra sleep if that
> switch is detected, if for some reason, the switch is not actually ready
> after the delays defined by the PCIe specification.
>
> (And btw. please test with the latest 6.18-rc, as, from experience, the
> ASPM problems in earlier RCs can result in some weird problems that are
> not immediately deduced to be caused by the ASPM enablement.)
>
>
> Kind regards,
> Niklas

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Niklas,

On 11/8/25 22:27, Niklas Cassel wrote:
(snip)> (And btw. please test with the latest 6.18-rc, as, from 
experience, the
> ASPM problems in earlier RCs can result in some weird problems that are
> not immediately deduced to be caused by the ASPM enablement.)

Here is dmesg from v6.18-rc4:
  https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Kind regards,
> Niklas
> 

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
> Hi Niklas,
> 
> On 11/8/25 22:27, Niklas Cassel wrote:
> (snip)> (And btw. please test with the latest 6.18-rc, as, from experience,
> the
> > ASPM problems in earlier RCs can result in some weird problems that are
> > not immediately deduced to be caused by the ASPM enablement.)
> 
> Here is dmesg from v6.18-rc4:
>  https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff

Same problem as before:
[    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
[    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.732661] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
[    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
[    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.732962] pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
[    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
[    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.733266] pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
[    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
[    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
[    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
[    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
[    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
[    1.733585] pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
[    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46


Seems like the ASM2806 switch, for some reason, is not ready.

One change that Diederik pointed out is that in the "good" case,
the link is always in Gen1 speed.

Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 214ed060ca1b..ac134d95a97f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
 {
 	static const struct pci_device_id ids[] = {
 		{ PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
+		{ PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
 		{}
 	};
 	u16 lnksta, lnkctl2;





If that does not work, perhaps you could try this patch
(assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
index dd7317bab613..26f8539d934a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
@@ -452,6 +452,7 @@ &pcie2x1l2 {
 	pinctrl-0 = <&pcie20x1_2_perstn_m0>;
 	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
 	vpcie3v3-supply = <&pcie2x1l2_3v3>;
+	max-link-speed = <1>;
 	status = "okay";
 };



Kind regards,
Niklas

Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Niklas,

On 11/9/25 21:28, Niklas Cassel wrote:
> On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
>> Hi Niklas,
>>
>> On 11/8/25 22:27, Niklas Cassel wrote:
>> (snip)> (And btw. please test with the latest 6.18-rc, as, from experience,
>> the
>>> ASPM problems in earlier RCs can result in some weird problems that are
>>> not immediately deduced to be caused by the ASPM enablement.)
>>
>> Here is dmesg from v6.18-rc4:
>>   https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff
> 
> Same problem as before:
> [    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> [    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732661] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> [    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> [    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732962] pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> [    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> [    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733266] pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> [    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> [    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> [    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> [    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> [    1.733585] pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> [    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> 
> 
> Seems like the ASM2806 switch, for some reason, is not ready.
> 
> One change that Diederik pointed out is that in the "good" case,
> the link is always in Gen1 speed.
> 
> Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 214ed060ca1b..ac134d95a97f 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>   {
>   	static const struct pci_device_id ids[] = {
>   		{ PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
> +		{ PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
>   		{}
>   	};
>   	u16 lnksta, lnkctl2;

It doesn't help with either probing behind the bridge or the link speed.

> If that does not work, perhaps you could try this patch
> (assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):

ROCK 5C has a PCIe FPC connector and I'm using Dual 2.5G Router HAT.
  https://radxa.com/products/rock5/5c#techspec
  https://radxa.com/products/accessories/dual-2-5g-router-hat

Regarding the link speed, I initially suspected the FPC connector and/or 
cable might be the issue. However, I tried the Dual 2.5G Router HAT with 
the ROCK 5A (which uses a different cable), and I got the same result.

BTW, the link speed varies between 2Gb/s and 4Gb/s depending on the 
reboot. (with or without quirk)

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
> index dd7317bab613..26f8539d934a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
> @@ -452,6 +452,7 @@ &pcie2x1l2 {
>   	pinctrl-0 = <&pcie20x1_2_perstn_m0>;
>   	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>   	vpcie3v3-supply = <&pcie2x1l2_3v3>;
> +	max-link-speed = <1>;
>   	status = "okay";
>   };
> 
> 
> 
> Kind regards,
> Niklas
> 

[RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

(RESEND: fix mani's email address)

Hi Niklas,

On 11/9/25 21:28, Niklas Cassel wrote:
> On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
>> Hi Niklas,
>>
>> On 11/8/25 22:27, Niklas Cassel wrote:
>> (snip)> (And btw. please test with the latest 6.18-rc, as, from experience,
>> the
>>> ASPM problems in earlier RCs can result in some weird problems that are
>>> not immediately deduced to be caused by the ASPM enablement.)
>>
>> Here is dmesg from v6.18-rc4:
>>   https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff
> 
> Same problem as before:
> [    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> [    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732661] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> [    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> [    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.732962] pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> [    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> [    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733266] pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> [    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> [    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> [    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> [    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> [    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> [    1.733585] pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> [    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> 
> 
> Seems like the ASM2806 switch, for some reason, is not ready.
> 
> One change that Diederik pointed out is that in the "good" case,
> the link is always in Gen1 speed.
> 
> Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 214ed060ca1b..ac134d95a97f 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>   {
>   	static const struct pci_device_id ids[] = {
>   		{ PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
> +		{ PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
>   		{}
>   	};
>   	u16 lnksta, lnkctl2;

It doesn't help with either probing behind the bridge or the link speed.

> If that does not work, perhaps you could try this patch
> (assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):

ROCK 5C has a PCIe FPC connector and I'm using Dual 2.5G Router HAT.
  https://radxa.com/products/rock5/5c#techspec
  https://radxa.com/products/accessories/dual-2-5g-router-hat

Regarding the link speed, I initially suspected the FPC connector and/or 
cable might be the issue. However, I tried the Dual 2.5G Router HAT with 
the ROCK 5A (which uses a different cable), and I got the same result.

BTW, the link speed varies between 2Gb/s and 4Gb/s depending on the 
reboot. (with or without quirk)

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
> index dd7317bab613..26f8539d934a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
> @@ -452,6 +452,7 @@ &pcie2x1l2 {
>   	pinctrl-0 = <&pcie20x1_2_perstn_m0>;
>   	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>   	vpcie3v3-supply = <&pcie2x1l2_3v3>;
> +	max-link-speed = <1>;
>   	status = "okay";
>   };
> 
> 
> 
> Kind regards,
> Niklas
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Shawn Lin]

Hi Fukaumi

在 2025/11/10 星期一 7:26, FUKAUMI Naoki 写道:
> (RESEND: fix mani's email address)
> 
> Hi Niklas,
> 
> On 11/9/25 21:28, Niklas Cassel wrote:
>> On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
>>> Hi Niklas,
>>>
>>> On 11/8/25 22:27, Niklas Cassel wrote:
>>> (snip)> (And btw. please test with the latest 6.18-rc, as, from 
>>> experience,
>>> the
>>>> ASPM problems in earlier RCs can result in some weird problems that are
>>>> not immediately deduced to be caused by the ASPM enablement.)
>>>
>>> Here is dmesg from v6.18-rc4:
>>>   https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff
>>
>> Same problem as before:
>> [    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated 
>> to 43
>> [    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.732661] pci 0004:42:00.0: devices behind bridge are unusable 
>> because [bus 43] cannot be assigned for them
>> [    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated 
>> to 44
>> [    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.732962] pci 0004:42:02.0: devices behind bridge are unusable 
>> because [bus 44] cannot be assigned for them
>> [    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated 
>> to 45
>> [    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.733266] pci 0004:42:06.0: devices behind bridge are unusable 
>> because [bus 45] cannot be assigned for them
>> [    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated 
>> to 46
>> [    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] 
>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>> [    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable 
>> because [bus 46] cannot be assigned for them
>> [    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated 
>> to 46
>> [    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] 
>> under [bus 41] (conflicts with (null) [bus 41])
>> [    1.733585] pci 0004:41:00.0: devices behind bridge are unusable 
>> because [bus 42-46] cannot be assigned for them
>> [    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but 
>> max busn 46
>>
>>
>> Seems like the ASM2806 switch, for some reason, is not ready.
>>
>> One change that Diederik pointed out is that in the "good" case,
>> the link is always in Gen1 speed.
>>
>> Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 214ed060ca1b..ac134d95a97f 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>>   {
>>       static const struct pci_device_id ids[] = {
>>           { PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
>> +        { PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
>>           {}
>>       };
>>       u16 lnksta, lnkctl2;
> 
> It doesn't help with either probing behind the bridge or the link speed.
> 
>> If that does not work, perhaps you could try this patch
>> (assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):
> 
> ROCK 5C has a PCIe FPC connector and I'm using Dual 2.5G Router HAT.
>   https://radxa.com/products/rock5/5c#techspec
>   https://radxa.com/products/accessories/dual-2-5g-router-hat
> 
> Regarding the link speed, I initially suspected the FPC connector and/or 
> cable might be the issue. However, I tried the Dual 2.5G Router HAT with 
> the ROCK 5A (which uses a different cable), and I got the same result.
> 
> BTW, the link speed varies between 2Gb/s and 4Gb/s depending on the 
> reboot. (with or without quirk)

Could you please help check this patch?

--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -454,6 +454,8 @@ static irqreturn_t 
rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
         struct dw_pcie *pci = &rockchip->pci;
         struct dw_pcie_rp *pp = &pci->pp;
         struct device *dev = pci->dev;
+       struct pci_bus *child, *root_bus = NULL;
+       struct pci_dev *bridge;
         u32 reg;

         reg = rockchip_pcie_readl_apb(rockchip, 
PCIE_CLIENT_INTR_STATUS_MISC);
@@ -462,12 +464,21 @@ static irqreturn_t 
rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
         dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg);
         dev_dbg(dev, "LTSSM_STATUS: %#x\n", 
rockchip_pcie_get_ltssm(rockchip));

+       list_for_each_entry(child, &pp->bridge->bus->children, node) {
+               if (child->parent == pp->bridge->bus) {
+                       root_bus = child;
+                       bridge = root_bus->self;
+                       break;
+               }
+        }
+
         if (reg & PCIE_RDLH_LINK_UP_CHGED) {
                 if (rockchip_pcie_link_up(pci)) {
                         msleep(PCIE_RESET_CONFIG_WAIT_MS);
                         dev_dbg(dev, "Received Link up event. Starting 
enumeration!\n");
                         /* Rescan the bus to enumerate endpoint devices */
                         pci_lock_rescan_remove();
+                       pci_stop_and_remove_bus_device(bridge);
                         pci_rescan_bus(pp->bridge->bus);
                         pci_unlock_rescan_remove();
                 }


> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/ 
>> arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>> index dd7317bab613..26f8539d934a 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>> @@ -452,6 +452,7 @@ &pcie2x1l2 {
>>       pinctrl-0 = <&pcie20x1_2_perstn_m0>;
>>       reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>>       vpcie3v3-supply = <&pcie2x1l2_3v3>;
>> +    max-link-speed = <1>;
>>       status = "okay";
>>   };
>>
>>
>>
>> Kind regards,
>> Niklas
>>
> 
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Shawn,

On 11/10/25 11:30, Shawn Lin wrote:
> Hi Fukaumi
> 
> 在 2025/11/10 星期一 7:26, FUKAUMI Naoki 写道:
>> (RESEND: fix mani's email address)
>>
>> Hi Niklas,
>>
>> On 11/9/25 21:28, Niklas Cassel wrote:
>>> On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
>>>> Hi Niklas,
>>>>
>>>> On 11/8/25 22:27, Niklas Cassel wrote:
>>>> (snip)> (And btw. please test with the latest 6.18-rc, as, from 
>>>> experience,
>>>> the
>>>>> ASPM problems in earlier RCs can result in some weird problems that 
>>>>> are
>>>>> not immediately deduced to be caused by the ASPM enablement.)
>>>>
>>>> Here is dmesg from v6.18-rc4:
>>>>   https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff
>>>
>>> Same problem as before:
>>> [    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated 
>>> to 43
>>> [    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.732661] pci 0004:42:00.0: devices behind bridge are unusable 
>>> because [bus 43] cannot be assigned for them
>>> [    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated 
>>> to 44
>>> [    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.732962] pci 0004:42:02.0: devices behind bridge are unusable 
>>> because [bus 44] cannot be assigned for them
>>> [    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated 
>>> to 45
>>> [    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.733266] pci 0004:42:06.0: devices behind bridge are unusable 
>>> because [bus 45] cannot be assigned for them
>>> [    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated 
>>> to 46
>>> [    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] 
>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>> [    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable 
>>> because [bus 46] cannot be assigned for them
>>> [    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated 
>>> to 46
>>> [    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] 
>>> under [bus 41] (conflicts with (null) [bus 41])
>>> [    1.733585] pci 0004:41:00.0: devices behind bridge are unusable 
>>> because [bus 42-46] cannot be assigned for them
>>> [    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but 
>>> max busn 46
>>>
>>>
>>> Seems like the ASM2806 switch, for some reason, is not ready.
>>>
>>> One change that Diederik pointed out is that in the "good" case,
>>> the link is always in Gen1 speed.
>>>
>>> Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:
>>>
>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>> index 214ed060ca1b..ac134d95a97f 100644
>>> --- a/drivers/pci/quirks.c
>>> +++ b/drivers/pci/quirks.c
>>> @@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>>>   {
>>>       static const struct pci_device_id ids[] = {
>>>           { PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
>>> +        { PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
>>>           {}
>>>       };
>>>       u16 lnksta, lnkctl2;
>>
>> It doesn't help with either probing behind the bridge or the link speed.
>>
>>> If that does not work, perhaps you could try this patch
>>> (assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):
>>
>> ROCK 5C has a PCIe FPC connector and I'm using Dual 2.5G Router HAT.
>>   https://radxa.com/products/rock5/5c#techspec
>>   https://radxa.com/products/accessories/dual-2-5g-router-hat
>>
>> Regarding the link speed, I initially suspected the FPC connector and/ 
>> or cable might be the issue. However, I tried the Dual 2.5G Router HAT 
>> with the ROCK 5A (which uses a different cable), and I got the same 
>> result.
>>
>> BTW, the link speed varies between 2Gb/s and 4Gb/s depending on the 
>> reboot. (with or without quirk)
> 
> Could you please help check this patch?

I tried your patch on top of vanilla v6.18-rc5.
  https://gist.github.com/RadxaNaoki/b42252ce3209d9f6bc2d4c90c71956ae

I got 2 oops,

- its_msi_teardown+0x120/0x140
   New with this patch.

- of_pci_add_properties+0x284/0x4c4
   It sometimes happen with vanilla v6.18-rcX.

Nothing behind the bridge is probed.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -454,6 +454,8 @@ static irqreturn_t 
> rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>          struct dw_pcie *pci = &rockchip->pci;
>          struct dw_pcie_rp *pp = &pci->pp;
>          struct device *dev = pci->dev;
> +       struct pci_bus *child, *root_bus = NULL;
> +       struct pci_dev *bridge;
>          u32 reg;
> 
>          reg = rockchip_pcie_readl_apb(rockchip, 
> PCIE_CLIENT_INTR_STATUS_MISC);
> @@ -462,12 +464,21 @@ static irqreturn_t 
> rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>          dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg);
>          dev_dbg(dev, "LTSSM_STATUS: %#x\n", 
> rockchip_pcie_get_ltssm(rockchip));
> 
> +       list_for_each_entry(child, &pp->bridge->bus->children, node) {
> +               if (child->parent == pp->bridge->bus) {
> +                       root_bus = child;
> +                       bridge = root_bus->self;
> +                       break;
> +               }
> +        }
> +
>          if (reg & PCIE_RDLH_LINK_UP_CHGED) {
>                  if (rockchip_pcie_link_up(pci)) {
>                          msleep(PCIE_RESET_CONFIG_WAIT_MS);
>                          dev_dbg(dev, "Received Link up event. Starting 
> enumeration!\n");
>                          /* Rescan the bus to enumerate endpoint devices */
>                          pci_lock_rescan_remove();
> +                       pci_stop_and_remove_bus_device(bridge);
>                          pci_rescan_bus(pp->bridge->bus);
>                          pci_unlock_rescan_remove();
>                  }
> 
> 
>>
>> Best regards,
>>
>> -- 
>> FUKAUMI Naoki
>> Radxa Computer (Shenzhen) Co., Ltd.
>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/ 
>>> arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>>> index dd7317bab613..26f8539d934a 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>>> @@ -452,6 +452,7 @@ &pcie2x1l2 {
>>>       pinctrl-0 = <&pcie20x1_2_perstn_m0>;
>>>       reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>>>       vpcie3v3-supply = <&pcie2x1l2_3v3>;
>>> +    max-link-speed = <1>;
>>>       status = "okay";
>>>   };
>>>
>>>
>>>
>>> Kind regards,
>>> Niklas
>>>
>>
>>
> 
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Shawn Lin]

在 2025/11/10 星期一 12:56, FUKAUMI Naoki 写道:
> Hi Shawn,
> 
> On 11/10/25 11:30, Shawn Lin wrote:
>> Hi Fukaumi
>>
>> 在 2025/11/10 星期一 7:26, FUKAUMI Naoki 写道:
>>> (RESEND: fix mani's email address)
>>>
>>> Hi Niklas,
>>>
>>> On 11/9/25 21:28, Niklas Cassel wrote:
>>>> On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
>>>>> Hi Niklas,
>>>>>
>>>>> On 11/8/25 22:27, Niklas Cassel wrote:
>>>>> (snip)> (And btw. please test with the latest 6.18-rc, as, from 
>>>>> experience,
>>>>> the
>>>>>> ASPM problems in earlier RCs can result in some weird problems 
>>>>>> that are
>>>>>> not immediately deduced to be caused by the ASPM enablement.)
>>>>>
>>>>> Here is dmesg from v6.18-rc4:
>>>>>   https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff
>>>>
>>>> Same problem as before:
>>>> [    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated 
>>>> to 43
>>>> [    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.732661] pci 0004:42:00.0: devices behind bridge are unusable 
>>>> because [bus 43] cannot be assigned for them
>>>> [    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated 
>>>> to 44
>>>> [    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.732962] pci 0004:42:02.0: devices behind bridge are unusable 
>>>> because [bus 44] cannot be assigned for them
>>>> [    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated 
>>>> to 45
>>>> [    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.733266] pci 0004:42:06.0: devices behind bridge are unusable 
>>>> because [bus 45] cannot be assigned for them
>>>> [    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated 
>>>> to 46
>>>> [    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] 
>>>> under [bus 42-41] (conflicts with (null) [bus 42-41])
>>>> [    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable 
>>>> because [bus 46] cannot be assigned for them
>>>> [    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated 
>>>> to 46
>>>> [    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] 
>>>> under [bus 41] (conflicts with (null) [bus 41])
>>>> [    1.733585] pci 0004:41:00.0: devices behind bridge are unusable 
>>>> because [bus 42-46] cannot be assigned for them
>>>> [    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but 
>>>> max busn 46
>>>>
>>>>
>>>> Seems like the ASM2806 switch, for some reason, is not ready.
>>>>
>>>> One change that Diederik pointed out is that in the "good" case,
>>>> the link is always in Gen1 speed.
>>>>
>>>> Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:
>>>>
>>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>>> index 214ed060ca1b..ac134d95a97f 100644
>>>> --- a/drivers/pci/quirks.c
>>>> +++ b/drivers/pci/quirks.c
>>>> @@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
>>>>   {
>>>>       static const struct pci_device_id ids[] = {
>>>>           { PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
>>>> +        { PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
>>>>           {}
>>>>       };
>>>>       u16 lnksta, lnkctl2;
>>>
>>> It doesn't help with either probing behind the bridge or the link speed.
>>>
>>>> If that does not work, perhaps you could try this patch
>>>> (assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):
>>>
>>> ROCK 5C has a PCIe FPC connector and I'm using Dual 2.5G Router HAT.
>>>   https://radxa.com/products/rock5/5c#techspec
>>>   https://radxa.com/products/accessories/dual-2-5g-router-hat
>>>
>>> Regarding the link speed, I initially suspected the FPC connector 
>>> and/ or cable might be the issue. However, I tried the Dual 2.5G 
>>> Router HAT with the ROCK 5A (which uses a different cable), and I got 
>>> the same result.
>>>
>>> BTW, the link speed varies between 2Gb/s and 4Gb/s depending on the 
>>> reboot. (with or without quirk)
>>
>> Could you please help check this patch?
> 
> I tried your patch on top of vanilla v6.18-rc5.
>   https://gist.github.com/RadxaNaoki/b42252ce3209d9f6bc2d4c90c71956ae
> 
> I got 2 oops,
> 
> - its_msi_teardown+0x120/0x140
>    New with this patch.
> 
> - of_pci_add_properties+0x284/0x4c4
>    It sometimes happen with vanilla v6.18-rcX.
> 
> Nothing behind the bridge is probed.

Hi Fukaumi,

Thanks for testing. I just got a ASM2806 switch as yours and verified it
on vanilla v6.18-rc5. After 30 times of cold boot, two NVMes behind
ASM2806 work as expected. Nothing special happened when I checked
with PA as well. You could help check the log and lspci dump there[1].

[1]https://pastebin.com/sAF1fT0g

> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> @@ -454,6 +454,8 @@ static irqreturn_t 
>> rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>>          struct dw_pcie *pci = &rockchip->pci;
>>          struct dw_pcie_rp *pp = &pci->pp;
>>          struct device *dev = pci->dev;
>> +       struct pci_bus *child, *root_bus = NULL;
>> +       struct pci_dev *bridge;
>>          u32 reg;
>>
>>          reg = rockchip_pcie_readl_apb(rockchip, 
>> PCIE_CLIENT_INTR_STATUS_MISC);
>> @@ -462,12 +464,21 @@ static irqreturn_t 
>> rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>>          dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg);
>>          dev_dbg(dev, "LTSSM_STATUS: %#x\n", 
>> rockchip_pcie_get_ltssm(rockchip));
>>
>> +       list_for_each_entry(child, &pp->bridge->bus->children, node) {
>> +               if (child->parent == pp->bridge->bus) {
>> +                       root_bus = child;
>> +                       bridge = root_bus->self;
>> +                       break;
>> +               }
>> +        }
>> +
>>          if (reg & PCIE_RDLH_LINK_UP_CHGED) {
>>                  if (rockchip_pcie_link_up(pci)) {
>>                          msleep(PCIE_RESET_CONFIG_WAIT_MS);
>>                          dev_dbg(dev, "Received Link up event. 
>> Starting enumeration!\n");
>>                          /* Rescan the bus to enumerate endpoint 
>> devices */
>>                          pci_lock_rescan_remove();
>> +                       pci_stop_and_remove_bus_device(bridge);
>>                          pci_rescan_bus(pp->bridge->bus);
>>                          pci_unlock_rescan_remove();
>>                  }
>>
>>
>>>
>>> Best regards,
>>>
>>> -- 
>>> FUKAUMI Naoki
>>> Radxa Computer (Shenzhen) Co., Ltd.
>>>
>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/ 
>>>> arch/ arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>>>> index dd7317bab613..26f8539d934a 100644
>>>> --- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
>>>> @@ -452,6 +452,7 @@ &pcie2x1l2 {
>>>>       pinctrl-0 = <&pcie20x1_2_perstn_m0>;
>>>>       reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>>>>       vpcie3v3-supply = <&pcie2x1l2_3v3>;
>>>> +    max-link-speed = <1>;
>>>>       status = "okay";
>>>>   };
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>> Niklas
>>>>
>>>
>>>
>>
>>
> 
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Shawn,

On 11/10/25 16:12, Shawn Lin wrote:
(snip)> Thanks for testing. I just got a ASM2806 switch as yours and 
verified it
> on vanilla v6.18-rc5. After 30 times of cold boot, two NVMes behind
> ASM2806 work as expected. Nothing special happened when I checked
> with PA as well. You could help check the log and lspci dump there[1].
> 
> [1]https://pastebin.com/sAF1fT0g

Thanks for the info!

I tried ASM2806 on Radxa ROCK 5B (RK3588).
  https://gist.github.com/RadxaNaoki/640e47d377add9fe38301de164d4058e

It doesn't work on PCIe 2.0 (M.2 E Key), but it does work on PCIe 3.0 
(M.2 M Key).

Could you try PCIe 2.0 slot on your board?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Shawn Lin]

在 2025/11/10 星期一 15:52, FUKAUMI Naoki 写道:
> Hi Shawn,
> 
> On 11/10/25 16:12, Shawn Lin wrote:
> (snip)> Thanks for testing. I just got a ASM2806 switch as yours and 
> verified it
>> on vanilla v6.18-rc5. After 30 times of cold boot, two NVMes behind
>> ASM2806 work as expected. Nothing special happened when I checked
>> with PA as well. You could help check the log and lspci dump there[1].
>>
>> [1]https://pastebin.com/sAF1fT0g
> 
> Thanks for the info!
> 
> I tried ASM2806 on Radxa ROCK 5B (RK3588).
>   https://gist.github.com/RadxaNaoki/640e47d377add9fe38301de164d4058e
> 
> It doesn't work on PCIe 2.0 (M.2 E Key), but it does work on PCIe 3.0 
> (M.2 M Key).
> 
> Could you try PCIe 2.0 slot on your board?

I did, it doesn't work on PCIe 2.0 slot. From the PA, I could see
the link is still in training during pci_host_probe() is called.
Add some delay before pci_rescan_bus() in pcie-dw-rockchip doesn't
help. But the below change should work as we delayed pci_host_probe().

--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -236,6 +236,8 @@ static int rockchip_pcie_start_link(struct dw_pcie *pci)
         msleep(PCIE_T_PVPERL_MS);
         gpiod_set_value_cansleep(rockchip->rst_gpio, 1);

+       msleep(50);
+
         return 0;

Otherwise we got:

[    0.841518] pci_bus 0003:33: busn_res: can not insert [bus 33-31] 
under [bus 32-31] (conflicts with (null) [bus 32-31])
[    0.842596] pci_bus 0003:33: busn_res: [bus 33-31] end is updated to 33
[    0.843184] pci_bus 0003:33: busn_res: can not insert [bus 33] under 
[bus 32-31] (conflicts with (null) [bus 32-31])
[    0.844120] pci 0003:32:00.0: devices behind bridge are unusable 
because [bus 33] cannot be assigned for them
[    0.845229] pci_bus 0003:34: busn_res: can not insert [bus 34-31] 
under [bus 32-31] (conflicts with (null) [bus 32-31])
[    0.846309] pci_bus 0003:34: busn_res: [bus 34-31] end is updated to 34
[    0.846898] pci_bus 0003:34: busn_res: can not insert [bus 34] under 
[bus 32-31] (conflicts with (null) [bus 32-31])
[    0.847833] pci 0003:32:06.0: devices behind bridge are unusable 
because [bus 34] cannot be assigned for them
[    0.848923] pci_bus 0003:35: busn_res: can not insert [bus 35-31] 
under [bus 32-31] (conflicts with (null) [bus 32-31])
[    0.850014] pci_bus 0003:35: busn_res: [bus 35-31] end is updated to 35
[    0.850605] pci_bus 0003:35: busn_res: can not insert [bus 35] under 
[bus 32-31] (conflicts with (null) [bus 32-31])
[    0.851540] pci 0003:32:0e.0: devices behind bridge are unusable 
because [bus 35] cannot be assigned for them
[    0.852424] pci_bus 0003:32: busn_res: [bus 32-31] end is updated to 35
[    0.853028] pci_bus 0003:32: busn_res: can not insert [bus 32-35] 
under [bus 31] (conflicts with (null) [bus 31])
[    0.853184] hub 3-0:1.0: USB hub found
[    0.853931] pci 0003:31:00.0: devices behind bridge are unusable 
because [bus 32-35] cannot be assigned for them
[    0.854262] hub 3-0:1.0: 1 port detected
[    0.855144] pcieport 0003:30:00.0: bridge has subordinate 31 but max 
busn 35
[    0.855722] hub 4-0:1.0: USB hub found
[    0.856109] pci 0003:32:00.0: PCI bridge to [bus 33]
[    0.856939] pci 0003:32:06.0: PCI bridge to [bus 34]
[    0.857133] hub 4-0:1.0: 1 port detected
[    0.857430] pci 0003:32:0e.0: PCI bridge to [bus 35]
[    0.858236] pci 0003:31:00.0: PCI bridge to [bus 32-35]

> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On Mon, Nov 10, 2025 at 06:15:33PM +0800, Shawn Lin wrote:
> > 
> > Could you try PCIe 2.0 slot on your board?
> 
> I did, it doesn't work on PCIe 2.0 slot. From the PA, I could see
> the link is still in training during pci_host_probe() is called.
> Add some delay before pci_rescan_bus() in pcie-dw-rockchip doesn't
> help. But the below change should work as we delayed pci_host_probe().
> 
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -236,6 +236,8 @@ static int rockchip_pcie_start_link(struct dw_pcie *pci)
>         msleep(PCIE_T_PVPERL_MS);
>         gpiod_set_value_cansleep(rockchip->rst_gpio, 1);
> 
> +       msleep(50);
> +
>         return 0;
> 
> Otherwise we got:
> 
> [    0.841518] pci_bus 0003:33: busn_res: can not insert [bus 33-31] under
> [bus 32-31] (conflicts with (null) [bus 32-31])
> [    0.842596] pci_bus 0003:33: busn_res: [bus 33-31] end is updated to 33
> [    0.843184] pci_bus 0003:33: busn_res: can not insert [bus 33] under [bus
> 32-31] (conflicts with (null) [bus 32-31])
> [    0.844120] pci 0003:32:00.0: devices behind bridge are unusable because
> [bus 33] cannot be assigned for them
> [    0.845229] pci_bus 0003:34: busn_res: can not insert [bus 34-31] under
> [bus 32-31] (conflicts with (null) [bus 32-31])
> [    0.846309] pci_bus 0003:34: busn_res: [bus 34-31] end is updated to 34
> [    0.846898] pci_bus 0003:34: busn_res: can not insert [bus 34] under [bus
> 32-31] (conflicts with (null) [bus 32-31])
> [    0.847833] pci 0003:32:06.0: devices behind bridge are unusable because
> [bus 34] cannot be assigned for them
> [    0.848923] pci_bus 0003:35: busn_res: can not insert [bus 35-31] under
> [bus 32-31] (conflicts with (null) [bus 32-31])
> [    0.850014] pci_bus 0003:35: busn_res: [bus 35-31] end is updated to 35
> [    0.850605] pci_bus 0003:35: busn_res: can not insert [bus 35] under [bus
> 32-31] (conflicts with (null) [bus 32-31])
> [    0.851540] pci 0003:32:0e.0: devices behind bridge are unusable because
> [bus 35] cannot be assigned for them
> [    0.852424] pci_bus 0003:32: busn_res: [bus 32-31] end is updated to 35
> [    0.853028] pci_bus 0003:32: busn_res: can not insert [bus 32-35] under
> [bus 31] (conflicts with (null) [bus 31])
> [    0.853184] hub 3-0:1.0: USB hub found
> [    0.853931] pci 0003:31:00.0: devices behind bridge are unusable because
> [bus 32-35] cannot be assigned for them
> [    0.854262] hub 3-0:1.0: 1 port detected
> [    0.855144] pcieport 0003:30:00.0: bridge has subordinate 31 but max busn
> 35
> [    0.855722] hub 4-0:1.0: USB hub found
> [    0.856109] pci 0003:32:00.0: PCI bridge to [bus 33]
> [    0.856939] pci 0003:32:06.0: PCI bridge to [bus 34]
> [    0.857133] hub 4-0:1.0: 1 port detected
> [    0.857430] pci 0003:32:0e.0: PCI bridge to [bus 35]
> [    0.858236] pci 0003:31:00.0: PCI bridge to [bus 32-35]

Mani,

while I see the idea behind your suggested hack:
 
+       if (pdev->vendor == 0x1d87 && pdev->device == 0x3588) {
+               pdev->is_hotplug_bridge = pdev->is_pciehp = 1;
+               return;
+       }


Considering what Shawn says, that the switch gets enumerated properly
if we simply add a msleep() in ->start_link(), which will be called
by dw_pcie_host_init() before pci_host_probe() is called...

...we already have a delay in the link up IRQ handler, before calling
pci_rescan_bus().

So, I think that the problem is that we are unconditionally calling
pci_host_probe() in dw_pcie_host_init(), even for platforms that have
a link-up IRQ.


I think a better solution would be something like:

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index e92513c5bda5..42d987ddab7d 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -565,6 +565,39 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
 	return 0;
 }
 
+static int dw_pcie_host_initial_scan(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct pci_host_bridge *bridge = pp->bridge;
+	int ret;
+
+	ret = pci_host_probe(bridge);
+	if (ret)
+		return ret;
+
+	if (pp->ops->post_init)
+		pp->ops->post_init(pp);
+
+	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
+
+	return 0;
+}
+
+void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
+{
+	if (!pp->initial_linkup_irq_done) {
+		if (dw_pcie_host_initial_scan(pp)) {
+			//TODO: cleanup
+		}
+		pp->initial_linkup_irq_done = true;
+	} else {
+		/* Rescan the bus to enumerate endpoint devices */
+		pci_lock_rescan_remove();
+		pci_rescan_bus(pp->bridge->bus);
+		pci_unlock_rescan_remove();
+	}
+}
+
 int dw_pcie_host_init(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -672,15 +705,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
 	if (!pp->use_linkup_irq)
 		/* Ignore errors, the link may come up later */
 		dw_pcie_wait_for_link(pci);
-
-	ret = pci_host_probe(bridge);
-	if (ret)
-		goto err_stop_link;
-
-	if (pp->ops->post_init)
-		pp->ops->post_init(pp);
-
-	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
+	else
+		/*
+		 * For platforms with Link Up IRQ, initial scan will be done
+		 * on first Link Up IRQ.
+		 */
+		if (dw_pcie_host_initial_scan(pp))
+			goto err_stop_link;
 
 	return 0;
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index e995f692a1ec..a31bd93490dc 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -427,6 +427,7 @@ struct dw_pcie_rp {
 	int			msg_atu_index;
 	struct resource		*msg_res;
 	bool			use_linkup_irq;
+	bool			initial_linkup_irq_done;
 	struct pci_eq_presets	presets;
 	struct pci_config_window *cfg;
 	bool			ecam_enabled;
@@ -807,6 +808,7 @@ void dw_pcie_msi_init(struct dw_pcie_rp *pp);
 int dw_pcie_msi_host_init(struct dw_pcie_rp *pp);
 void dw_pcie_free_msi(struct dw_pcie_rp *pp);
 int dw_pcie_setup_rc(struct dw_pcie_rp *pp);
+void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp);
 int dw_pcie_host_init(struct dw_pcie_rp *pp);
 void dw_pcie_host_deinit(struct dw_pcie_rp *pp);
 int dw_pcie_allocate_domains(struct dw_pcie_rp *pp);
@@ -844,6 +846,9 @@ static inline int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
 	return 0;
 }
 
+static inline void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
+{ }
+
 static inline int dw_pcie_host_init(struct dw_pcie_rp *pp)
 {
 	return 0;
diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 8a882dcd1e4e..042e5845bdd6 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -468,10 +468,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
 		if (rockchip_pcie_link_up(pci)) {
 			msleep(PCIE_RESET_CONFIG_WAIT_MS);
 			dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
-			/* Rescan the bus to enumerate endpoint devices */
-			pci_lock_rescan_remove();
-			pci_rescan_bus(pp->bridge->bus);
-			pci_unlock_rescan_remove();
+			dw_pcie_handle_link_up_irq(pp);
 		}
 	}
 




What do you think?



Kind regards,
Niklas

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On Mon, Nov 10, 2025 at 01:34:41PM +0100, Niklas Cassel wrote:
> @@ -672,15 +705,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>  	if (!pp->use_linkup_irq)
>  		/* Ignore errors, the link may come up later */
>  		dw_pcie_wait_for_link(pci);
> -
> -	ret = pci_host_probe(bridge);
> -	if (ret)
> -		goto err_stop_link;
> -
> -	if (pp->ops->post_init)
> -		pp->ops->post_init(pp);
> -
> -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> +	else
> +		/*
> +		 * For platforms with Link Up IRQ, initial scan will be done
> +		 * on first Link Up IRQ.
> +		 */
> +		if (dw_pcie_host_initial_scan(pp))
> +			goto err_stop_link;

Oops.. this condition was inverted, what I meant was:

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index e92513c5bda5..0e04c1d6d260 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -565,6 +565,39 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
 	return 0;
 }
 
+static int dw_pcie_host_initial_scan(struct dw_pcie_rp *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct pci_host_bridge *bridge = pp->bridge;
+	int ret;
+
+	ret = pci_host_probe(bridge);
+	if (ret)
+		return ret;
+
+	if (pp->ops->post_init)
+		pp->ops->post_init(pp);
+
+	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
+
+	return 0;
+}
+
+void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
+{
+	if (!pp->initial_linkup_irq_done) {
+		if (dw_pcie_host_initial_scan(pp)) {
+			//TODO: cleanup
+		}
+		pp->initial_linkup_irq_done = true;
+	} else {
+		/* Rescan the bus to enumerate endpoint devices */
+		pci_lock_rescan_remove();
+		pci_rescan_bus(pp->bridge->bus);
+		pci_unlock_rescan_remove();
+	}
+}
+
 int dw_pcie_host_init(struct dw_pcie_rp *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -669,18 +702,17 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
 	 * If there is no Link Up IRQ, we should not bypass the delay
 	 * because that would require users to manually rescan for devices.
 	 */
-	if (!pp->use_linkup_irq)
+	if (!pp->use_linkup_irq) {
 		/* Ignore errors, the link may come up later */
 		dw_pcie_wait_for_link(pci);
 
-	ret = pci_host_probe(bridge);
-	if (ret)
-		goto err_stop_link;
-
-	if (pp->ops->post_init)
-		pp->ops->post_init(pp);
-
-	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
+		/*
+		 * For platforms with Link Up IRQ, initial scan will be done
+		 * on first Link Up IRQ.
+		 */
+		if (dw_pcie_host_initial_scan(pp))
+			goto err_stop_link;
+	}
 
 	return 0;
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index e995f692a1ec..a31bd93490dc 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -427,6 +427,7 @@ struct dw_pcie_rp {
 	int			msg_atu_index;
 	struct resource		*msg_res;
 	bool			use_linkup_irq;
+	bool			initial_linkup_irq_done;
 	struct pci_eq_presets	presets;
 	struct pci_config_window *cfg;
 	bool			ecam_enabled;
@@ -807,6 +808,7 @@ void dw_pcie_msi_init(struct dw_pcie_rp *pp);
 int dw_pcie_msi_host_init(struct dw_pcie_rp *pp);
 void dw_pcie_free_msi(struct dw_pcie_rp *pp);
 int dw_pcie_setup_rc(struct dw_pcie_rp *pp);
+void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp);
 int dw_pcie_host_init(struct dw_pcie_rp *pp);
 void dw_pcie_host_deinit(struct dw_pcie_rp *pp);
 int dw_pcie_allocate_domains(struct dw_pcie_rp *pp);
@@ -844,6 +846,9 @@ static inline int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
 	return 0;
 }
 
+static inline void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
+{ }
+
 static inline int dw_pcie_host_init(struct dw_pcie_rp *pp)
 {
 	return 0;
diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 8a882dcd1e4e..042e5845bdd6 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -468,10 +468,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
 		if (rockchip_pcie_link_up(pci)) {
 			msleep(PCIE_RESET_CONFIG_WAIT_MS);
 			dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
-			/* Rescan the bus to enumerate endpoint devices */
-			pci_lock_rescan_remove();
-			pci_rescan_bus(pp->bridge->bus);
-			pci_unlock_rescan_remove();
+			dw_pcie_handle_link_up_irq(pp);
 		}
 	}
 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Shawn, Mani, Niklas,

I'm testing your patches on ROCK 5A/5C, but the behavior is 
inconsistent. Sometimes it works, sometimes it doesn't, and sometimes I 
get an oops. I'm a bit confused, so I'll try again tomorrow.

BTW, do you have any idea about this oops?

[    1.680251] Unable to handle kernel NULL pointer dereference at 
virtual address 0000000000000080
[    1.681039] Mem abort info:
[    1.681294]   ESR = 0x0000000096000004
[    1.681627]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.682101]   SET = 0, FnV = 0
[    1.682382]   EA = 0, S1PTW = 0
[    1.682662]   FSC = 0x04: level 0 translation fault
[    1.683119] Data abort info:
[    1.683381]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[    1.683869]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    1.684324]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    1.684798] user pgtable: 4k pages, 48-bit VAs, pgdp=000000005630d000
[    1.685374] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000
[    1.685983] Internal error: Oops: 0000000096000004 [#1]  SMP
[    1.686483] Modules linked in: phy_rockchip_usbdp typec 
phy_rockchip_naneng_combphy phy_rockchip_samsung_hdptx dwmac_rk 
stmmac_platform stmmac pcs_xpcs rockchipdrm dw_hdmi_qp analogix_dp 
dw_hdmi dw_mipi_dsi drm_dp_aux_bus drm_display_helper cec drm_client_lib 
drm_dma_helper drm_kms_helper drm backlight
[    1.688881] CPU: 0 UID: 0 PID: 171 Comm: irq/87-pcie-sys Tainted: G 
      W           6.18.0-rc5-dirty #2 PREEMPT
[    1.689801] Tainted: [W]=WARN
[    1.690066] Hardware name: radxa Radxa ROCK 5C/Radxa ROCK 5C, BIOS 
2025.10-00012-g0c3aff620204-dirty 10/01/2025
[    1.690952] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)
[    1.691567] pc : of_pci_add_properties+0x284/0x4c4
[    1.692000] lr : of_pci_add_properties+0x264/0x4c4
[    1.692426] sp : ffff8000813fbbf0
[    1.692722] x29: ffff8000813fbc40 x28: ffffcfffe906b3b8 x27: 
ffffcfffeb95b1d0
[    1.693358] x26: ffff000001236980 x25: ffff00007452ceac x24: 
ffff000008844600
[    1.693993] x23: ffff00007452ce00 x22: ffff0000073b3a00 x21: 
ffff00000045db10
[    1.694628] x20: ffff00000057c000 x19: 0000000000000000 x18: 
00000000ffffffff
[    1.695264] x17: 0000000000000000 x16: 0000000000000000 x15: 
ffff8000813fba70
[    1.695898] x14: ffff000000c355b8 x13: ffff000000c355b6 x12: 
0000000000000000
[    1.696533] x11: 00333634353d4d55 x10: 000000000000002c x9 : 
0000000000000000
[    1.697168] x8 : ffff00007479c800 x7 : 0000000000000000 x6 : 
0000000000696370
[    1.697803] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 
ffff8000813fbc20
[    1.698439] x2 : ffffcfffeabc6ef0 x1 : ffff0000073b3a00 x0 : 
0000000000000000
[    1.699074] Call trace:
[    1.699293]  of_pci_add_properties+0x284/0x4c4 (P)
[    1.699723]  of_pci_make_dev_node+0xd8/0x150
[    1.700109]  pci_bus_add_device+0x138/0x168
[    1.700485]  pci_bus_add_devices+0x3c/0x88
[    1.700853]  pci_bus_add_devices+0x68/0x88
[    1.701220]  pci_rescan_bus+0x30/0x44
[    1.701551]  rockchip_pcie_rc_sys_irq_thread+0xb8/0xd0
[    1.702010]  irq_thread_fn+0x2c/0xa8
[    1.702333]  irq_thread+0x168/0x320
[    1.702648]  kthread+0x12c/0x204
[    1.702941]  ret_from_fork+0x10/0x20
[    1.703267] Code: aa1603e1 f000abc2 d2800044 913bc042 (f94040a0)

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 11/10/25 21:41, Niklas Cassel wrote:
> On Mon, Nov 10, 2025 at 01:34:41PM +0100, Niklas Cassel wrote:
>> @@ -672,15 +705,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>   	if (!pp->use_linkup_irq)
>>   		/* Ignore errors, the link may come up later */
>>   		dw_pcie_wait_for_link(pci);
>> -
>> -	ret = pci_host_probe(bridge);
>> -	if (ret)
>> -		goto err_stop_link;
>> -
>> -	if (pp->ops->post_init)
>> -		pp->ops->post_init(pp);
>> -
>> -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
>> +	else
>> +		/*
>> +		 * For platforms with Link Up IRQ, initial scan will be done
>> +		 * on first Link Up IRQ.
>> +		 */
>> +		if (dw_pcie_host_initial_scan(pp))
>> +			goto err_stop_link;
> 
> Oops.. this condition was inverted, what I meant was:
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index e92513c5bda5..0e04c1d6d260 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -565,6 +565,39 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>   	return 0;
>   }
>   
> +static int dw_pcie_host_initial_scan(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct pci_host_bridge *bridge = pp->bridge;
> +	int ret;
> +
> +	ret = pci_host_probe(bridge);
> +	if (ret)
> +		return ret;
> +
> +	if (pp->ops->post_init)
> +		pp->ops->post_init(pp);
> +
> +	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> +
> +	return 0;
> +}
> +
> +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
> +{
> +	if (!pp->initial_linkup_irq_done) {
> +		if (dw_pcie_host_initial_scan(pp)) {
> +			//TODO: cleanup
> +		}
> +		pp->initial_linkup_irq_done = true;
> +	} else {
> +		/* Rescan the bus to enumerate endpoint devices */
> +		pci_lock_rescan_remove();
> +		pci_rescan_bus(pp->bridge->bus);
> +		pci_unlock_rescan_remove();
> +	}
> +}
> +
>   int dw_pcie_host_init(struct dw_pcie_rp *pp)
>   {
>   	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> @@ -669,18 +702,17 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>   	 * If there is no Link Up IRQ, we should not bypass the delay
>   	 * because that would require users to manually rescan for devices.
>   	 */
> -	if (!pp->use_linkup_irq)
> +	if (!pp->use_linkup_irq) {
>   		/* Ignore errors, the link may come up later */
>   		dw_pcie_wait_for_link(pci);
>   
> -	ret = pci_host_probe(bridge);
> -	if (ret)
> -		goto err_stop_link;
> -
> -	if (pp->ops->post_init)
> -		pp->ops->post_init(pp);
> -
> -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> +		/*
> +		 * For platforms with Link Up IRQ, initial scan will be done
> +		 * on first Link Up IRQ.
> +		 */
> +		if (dw_pcie_host_initial_scan(pp))
> +			goto err_stop_link;
> +	}
>   
>   	return 0;
>   
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index e995f692a1ec..a31bd93490dc 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -427,6 +427,7 @@ struct dw_pcie_rp {
>   	int			msg_atu_index;
>   	struct resource		*msg_res;
>   	bool			use_linkup_irq;
> +	bool			initial_linkup_irq_done;
>   	struct pci_eq_presets	presets;
>   	struct pci_config_window *cfg;
>   	bool			ecam_enabled;
> @@ -807,6 +808,7 @@ void dw_pcie_msi_init(struct dw_pcie_rp *pp);
>   int dw_pcie_msi_host_init(struct dw_pcie_rp *pp);
>   void dw_pcie_free_msi(struct dw_pcie_rp *pp);
>   int dw_pcie_setup_rc(struct dw_pcie_rp *pp);
> +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp);
>   int dw_pcie_host_init(struct dw_pcie_rp *pp);
>   void dw_pcie_host_deinit(struct dw_pcie_rp *pp);
>   int dw_pcie_allocate_domains(struct dw_pcie_rp *pp);
> @@ -844,6 +846,9 @@ static inline int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
>   	return 0;
>   }
>   
> +static inline void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
> +{ }
> +
>   static inline int dw_pcie_host_init(struct dw_pcie_rp *pp)
>   {
>   	return 0;
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 8a882dcd1e4e..042e5845bdd6 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -468,10 +468,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>   		if (rockchip_pcie_link_up(pci)) {
>   			msleep(PCIE_RESET_CONFIG_WAIT_MS);
>   			dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
> -			/* Rescan the bus to enumerate endpoint devices */
> -			pci_lock_rescan_remove();
> -			pci_rescan_bus(pp->bridge->bus);
> -			pci_unlock_rescan_remove();
> +			dw_pcie_handle_link_up_irq(pp);
>   		}
>   	}
>   
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Manivannan Sadhasivam]

On Tue, Nov 11, 2025 at 12:21:20AM +0900, FUKAUMI Naoki wrote:
> Hi Shawn, Mani, Niklas,
> 
> I'm testing your patches on ROCK 5A/5C, but the behavior is inconsistent.
> Sometimes it works, sometimes it doesn't, and sometimes I get an oops. I'm a
> bit confused, so I'll try again tomorrow.
> 
> BTW, do you have any idea about this oops?
> 

I don't know why this is happening, but looks like it is coming from
CONFIG_PCI_DYNAMIC_OF_NODES. You can unset it and give it a try.

- Mani

> [    1.680251] Unable to handle kernel NULL pointer dereference at virtual
> address 0000000000000080
> [    1.681039] Mem abort info:
> [    1.681294]   ESR = 0x0000000096000004
> [    1.681627]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    1.682101]   SET = 0, FnV = 0
> [    1.682382]   EA = 0, S1PTW = 0
> [    1.682662]   FSC = 0x04: level 0 translation fault
> [    1.683119] Data abort info:
> [    1.683381]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [    1.683869]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [    1.684324]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [    1.684798] user pgtable: 4k pages, 48-bit VAs, pgdp=000000005630d000
> [    1.685374] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000
> [    1.685983] Internal error: Oops: 0000000096000004 [#1]  SMP
> [    1.686483] Modules linked in: phy_rockchip_usbdp typec
> phy_rockchip_naneng_combphy phy_rockchip_samsung_hdptx dwmac_rk
> stmmac_platform stmmac pcs_xpcs rockchipdrm dw_hdmi_qp analogix_dp dw_hdmi
> dw_mipi_dsi drm_dp_aux_bus drm_display_helper cec drm_client_lib
> drm_dma_helper drm_kms_helper drm backlight
> [    1.688881] CPU: 0 UID: 0 PID: 171 Comm: irq/87-pcie-sys Tainted: G
> W           6.18.0-rc5-dirty #2 PREEMPT
> [    1.689801] Tainted: [W]=WARN
> [    1.690066] Hardware name: radxa Radxa ROCK 5C/Radxa ROCK 5C, BIOS
> 2025.10-00012-g0c3aff620204-dirty 10/01/2025
> [    1.690952] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [    1.691567] pc : of_pci_add_properties+0x284/0x4c4
> [    1.692000] lr : of_pci_add_properties+0x264/0x4c4
> [    1.692426] sp : ffff8000813fbbf0
> [    1.692722] x29: ffff8000813fbc40 x28: ffffcfffe906b3b8 x27:
> ffffcfffeb95b1d0
> [    1.693358] x26: ffff000001236980 x25: ffff00007452ceac x24:
> ffff000008844600
> [    1.693993] x23: ffff00007452ce00 x22: ffff0000073b3a00 x21:
> ffff00000045db10
> [    1.694628] x20: ffff00000057c000 x19: 0000000000000000 x18:
> 00000000ffffffff
> [    1.695264] x17: 0000000000000000 x16: 0000000000000000 x15:
> ffff8000813fba70
> [    1.695898] x14: ffff000000c355b8 x13: ffff000000c355b6 x12:
> 0000000000000000
> [    1.696533] x11: 00333634353d4d55 x10: 000000000000002c x9 :
> 0000000000000000
> [    1.697168] x8 : ffff00007479c800 x7 : 0000000000000000 x6 :
> 0000000000696370
> [    1.697803] x5 : 0000000000000000 x4 : 0000000000000002 x3 :
> ffff8000813fbc20
> [    1.698439] x2 : ffffcfffeabc6ef0 x1 : ffff0000073b3a00 x0 :
> 0000000000000000
> [    1.699074] Call trace:
> [    1.699293]  of_pci_add_properties+0x284/0x4c4 (P)
> [    1.699723]  of_pci_make_dev_node+0xd8/0x150
> [    1.700109]  pci_bus_add_device+0x138/0x168
> [    1.700485]  pci_bus_add_devices+0x3c/0x88
> [    1.700853]  pci_bus_add_devices+0x68/0x88
> [    1.701220]  pci_rescan_bus+0x30/0x44
> [    1.701551]  rockchip_pcie_rc_sys_irq_thread+0xb8/0xd0
> [    1.702010]  irq_thread_fn+0x2c/0xa8
> [    1.702333]  irq_thread+0x168/0x320
> [    1.702648]  kthread+0x12c/0x204
> [    1.702941]  ret_from_fork+0x10/0x20
> [    1.703267] Code: aa1603e1 f000abc2 d2800044 913bc042 (f94040a0)
> 
> Best regards,
> 
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
> On 11/10/25 21:41, Niklas Cassel wrote:
> > On Mon, Nov 10, 2025 at 01:34:41PM +0100, Niklas Cassel wrote:
> > > @@ -672,15 +705,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
> > >   	if (!pp->use_linkup_irq)
> > >   		/* Ignore errors, the link may come up later */
> > >   		dw_pcie_wait_for_link(pci);
> > > -
> > > -	ret = pci_host_probe(bridge);
> > > -	if (ret)
> > > -		goto err_stop_link;
> > > -
> > > -	if (pp->ops->post_init)
> > > -		pp->ops->post_init(pp);
> > > -
> > > -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> > > +	else
> > > +		/*
> > > +		 * For platforms with Link Up IRQ, initial scan will be done
> > > +		 * on first Link Up IRQ.
> > > +		 */
> > > +		if (dw_pcie_host_initial_scan(pp))
> > > +			goto err_stop_link;
> > 
> > Oops.. this condition was inverted, what I meant was:
> > 
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > index e92513c5bda5..0e04c1d6d260 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > @@ -565,6 +565,39 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
> >   	return 0;
> >   }
> > +static int dw_pcie_host_initial_scan(struct dw_pcie_rp *pp)
> > +{
> > +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > +	struct pci_host_bridge *bridge = pp->bridge;
> > +	int ret;
> > +
> > +	ret = pci_host_probe(bridge);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (pp->ops->post_init)
> > +		pp->ops->post_init(pp);
> > +
> > +	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> > +
> > +	return 0;
> > +}
> > +
> > +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
> > +{
> > +	if (!pp->initial_linkup_irq_done) {
> > +		if (dw_pcie_host_initial_scan(pp)) {
> > +			//TODO: cleanup
> > +		}
> > +		pp->initial_linkup_irq_done = true;
> > +	} else {
> > +		/* Rescan the bus to enumerate endpoint devices */
> > +		pci_lock_rescan_remove();
> > +		pci_rescan_bus(pp->bridge->bus);
> > +		pci_unlock_rescan_remove();
> > +	}
> > +}
> > +
> >   int dw_pcie_host_init(struct dw_pcie_rp *pp)
> >   {
> >   	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > @@ -669,18 +702,17 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
> >   	 * If there is no Link Up IRQ, we should not bypass the delay
> >   	 * because that would require users to manually rescan for devices.
> >   	 */
> > -	if (!pp->use_linkup_irq)
> > +	if (!pp->use_linkup_irq) {
> >   		/* Ignore errors, the link may come up later */
> >   		dw_pcie_wait_for_link(pci);
> > -	ret = pci_host_probe(bridge);
> > -	if (ret)
> > -		goto err_stop_link;
> > -
> > -	if (pp->ops->post_init)
> > -		pp->ops->post_init(pp);
> > -
> > -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> > +		/*
> > +		 * For platforms with Link Up IRQ, initial scan will be done
> > +		 * on first Link Up IRQ.
> > +		 */
> > +		if (dw_pcie_host_initial_scan(pp))
> > +			goto err_stop_link;
> > +	}
> >   	return 0;
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> > index e995f692a1ec..a31bd93490dc 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -427,6 +427,7 @@ struct dw_pcie_rp {
> >   	int			msg_atu_index;
> >   	struct resource		*msg_res;
> >   	bool			use_linkup_irq;
> > +	bool			initial_linkup_irq_done;
> >   	struct pci_eq_presets	presets;
> >   	struct pci_config_window *cfg;
> >   	bool			ecam_enabled;
> > @@ -807,6 +808,7 @@ void dw_pcie_msi_init(struct dw_pcie_rp *pp);
> >   int dw_pcie_msi_host_init(struct dw_pcie_rp *pp);
> >   void dw_pcie_free_msi(struct dw_pcie_rp *pp);
> >   int dw_pcie_setup_rc(struct dw_pcie_rp *pp);
> > +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp);
> >   int dw_pcie_host_init(struct dw_pcie_rp *pp);
> >   void dw_pcie_host_deinit(struct dw_pcie_rp *pp);
> >   int dw_pcie_allocate_domains(struct dw_pcie_rp *pp);
> > @@ -844,6 +846,9 @@ static inline int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
> >   	return 0;
> >   }
> > +static inline void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
> > +{ }
> > +
> >   static inline int dw_pcie_host_init(struct dw_pcie_rp *pp)
> >   {
> >   	return 0;
> > diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > index 8a882dcd1e4e..042e5845bdd6 100644
> > --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > @@ -468,10 +468,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
> >   		if (rockchip_pcie_link_up(pci)) {
> >   			msleep(PCIE_RESET_CONFIG_WAIT_MS);
> >   			dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
> > -			/* Rescan the bus to enumerate endpoint devices */
> > -			pci_lock_rescan_remove();
> > -			pci_rescan_bus(pp->bridge->bus);
> > -			pci_unlock_rescan_remove();
> > +			dw_pcie_handle_link_up_irq(pp);
> >   		}
> >   	}
> > 
> 

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

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Manivannan Sadhasivam]

On Mon, Nov 10, 2025 at 01:34:41PM +0100, Niklas Cassel wrote:
> On Mon, Nov 10, 2025 at 06:15:33PM +0800, Shawn Lin wrote:
> > > 
> > > Could you try PCIe 2.0 slot on your board?
> > 
> > I did, it doesn't work on PCIe 2.0 slot. From the PA, I could see
> > the link is still in training during pci_host_probe() is called.
> > Add some delay before pci_rescan_bus() in pcie-dw-rockchip doesn't
> > help. But the below change should work as we delayed pci_host_probe().
> > 
> > --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> > @@ -236,6 +236,8 @@ static int rockchip_pcie_start_link(struct dw_pcie *pci)
> >         msleep(PCIE_T_PVPERL_MS);
> >         gpiod_set_value_cansleep(rockchip->rst_gpio, 1);
> > 
> > +       msleep(50);
> > +
> >         return 0;
> > 
> > Otherwise we got:
> > 
> > [    0.841518] pci_bus 0003:33: busn_res: can not insert [bus 33-31] under
> > [bus 32-31] (conflicts with (null) [bus 32-31])
> > [    0.842596] pci_bus 0003:33: busn_res: [bus 33-31] end is updated to 33
> > [    0.843184] pci_bus 0003:33: busn_res: can not insert [bus 33] under [bus
> > 32-31] (conflicts with (null) [bus 32-31])
> > [    0.844120] pci 0003:32:00.0: devices behind bridge are unusable because
> > [bus 33] cannot be assigned for them
> > [    0.845229] pci_bus 0003:34: busn_res: can not insert [bus 34-31] under
> > [bus 32-31] (conflicts with (null) [bus 32-31])
> > [    0.846309] pci_bus 0003:34: busn_res: [bus 34-31] end is updated to 34
> > [    0.846898] pci_bus 0003:34: busn_res: can not insert [bus 34] under [bus
> > 32-31] (conflicts with (null) [bus 32-31])
> > [    0.847833] pci 0003:32:06.0: devices behind bridge are unusable because
> > [bus 34] cannot be assigned for them
> > [    0.848923] pci_bus 0003:35: busn_res: can not insert [bus 35-31] under
> > [bus 32-31] (conflicts with (null) [bus 32-31])
> > [    0.850014] pci_bus 0003:35: busn_res: [bus 35-31] end is updated to 35
> > [    0.850605] pci_bus 0003:35: busn_res: can not insert [bus 35] under [bus
> > 32-31] (conflicts with (null) [bus 32-31])
> > [    0.851540] pci 0003:32:0e.0: devices behind bridge are unusable because
> > [bus 35] cannot be assigned for them
> > [    0.852424] pci_bus 0003:32: busn_res: [bus 32-31] end is updated to 35
> > [    0.853028] pci_bus 0003:32: busn_res: can not insert [bus 32-35] under
> > [bus 31] (conflicts with (null) [bus 31])
> > [    0.853184] hub 3-0:1.0: USB hub found
> > [    0.853931] pci 0003:31:00.0: devices behind bridge are unusable because
> > [bus 32-35] cannot be assigned for them
> > [    0.854262] hub 3-0:1.0: 1 port detected
> > [    0.855144] pcieport 0003:30:00.0: bridge has subordinate 31 but max busn
> > 35
> > [    0.855722] hub 4-0:1.0: USB hub found
> > [    0.856109] pci 0003:32:00.0: PCI bridge to [bus 33]
> > [    0.856939] pci 0003:32:06.0: PCI bridge to [bus 34]
> > [    0.857133] hub 4-0:1.0: 1 port detected
> > [    0.857430] pci 0003:32:0e.0: PCI bridge to [bus 35]
> > [    0.858236] pci 0003:31:00.0: PCI bridge to [bus 32-35]
> 
> Mani,
> 
> while I see the idea behind your suggested hack:
>  
> +       if (pdev->vendor == 0x1d87 && pdev->device == 0x3588) {
> +               pdev->is_hotplug_bridge = pdev->is_pciehp = 1;
> +               return;
> +       }
> 
> 
> Considering what Shawn says, that the switch gets enumerated properly
> if we simply add a msleep() in ->start_link(), which will be called
> by dw_pcie_host_init() before pci_host_probe() is called...
> 

Yes, that delay probably gives enough time for the link up IRQ to kick in before
the initial bus scan happens.

> ...we already have a delay in the link up IRQ handler, before calling
> pci_rescan_bus().
> 

That delay won't help in this case.

> So, I think that the problem is that we are unconditionally calling
> pci_host_probe() in dw_pcie_host_init(), even for platforms that have
> a link-up IRQ.
> 
> 
> I think a better solution would be something like:
> 

This solution will work as long as the PCIe device is powered ON before
start_link(). For CEM and M.2 Key M connectors, the host controller can power
manage the components. But for other specifications/keys requiring custom power
management, a separate driver would be needed.

That's why I suggested using pwrctrl framework as it can satisfy both usecases.
However, as I said, it needs a bit of rework and I'm close to submitting it.

But until that gets merged, either we need to revert your link up IRQ change or
have the below patch. IMO, the revert seems simple.

- Mani

> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index e92513c5bda5..42d987ddab7d 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -565,6 +565,39 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>  	return 0;
>  }
>  
> +static int dw_pcie_host_initial_scan(struct dw_pcie_rp *pp)
> +{
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct pci_host_bridge *bridge = pp->bridge;
> +	int ret;
> +
> +	ret = pci_host_probe(bridge);
> +	if (ret)
> +		return ret;
> +
> +	if (pp->ops->post_init)
> +		pp->ops->post_init(pp);
> +
> +	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> +
> +	return 0;
> +}
> +
> +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
> +{
> +	if (!pp->initial_linkup_irq_done) {
> +		if (dw_pcie_host_initial_scan(pp)) {
> +			//TODO: cleanup
> +		}
> +		pp->initial_linkup_irq_done = true;
> +	} else {
> +		/* Rescan the bus to enumerate endpoint devices */
> +		pci_lock_rescan_remove();
> +		pci_rescan_bus(pp->bridge->bus);
> +		pci_unlock_rescan_remove();
> +	}
> +}
> +
>  int dw_pcie_host_init(struct dw_pcie_rp *pp)
>  {
>  	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> @@ -672,15 +705,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>  	if (!pp->use_linkup_irq)
>  		/* Ignore errors, the link may come up later */
>  		dw_pcie_wait_for_link(pci);
> -
> -	ret = pci_host_probe(bridge);
> -	if (ret)
> -		goto err_stop_link;
> -
> -	if (pp->ops->post_init)
> -		pp->ops->post_init(pp);
> -
> -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
> +	else
> +		/*
> +		 * For platforms with Link Up IRQ, initial scan will be done
> +		 * on first Link Up IRQ.
> +		 */
> +		if (dw_pcie_host_initial_scan(pp))
> +			goto err_stop_link;
>  
>  	return 0;
>  
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index e995f692a1ec..a31bd93490dc 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -427,6 +427,7 @@ struct dw_pcie_rp {
>  	int			msg_atu_index;
>  	struct resource		*msg_res;
>  	bool			use_linkup_irq;
> +	bool			initial_linkup_irq_done;
>  	struct pci_eq_presets	presets;
>  	struct pci_config_window *cfg;
>  	bool			ecam_enabled;
> @@ -807,6 +808,7 @@ void dw_pcie_msi_init(struct dw_pcie_rp *pp);
>  int dw_pcie_msi_host_init(struct dw_pcie_rp *pp);
>  void dw_pcie_free_msi(struct dw_pcie_rp *pp);
>  int dw_pcie_setup_rc(struct dw_pcie_rp *pp);
> +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp);
>  int dw_pcie_host_init(struct dw_pcie_rp *pp);
>  void dw_pcie_host_deinit(struct dw_pcie_rp *pp);
>  int dw_pcie_allocate_domains(struct dw_pcie_rp *pp);
> @@ -844,6 +846,9 @@ static inline int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
>  	return 0;
>  }
>  
> +static inline void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
> +{ }
> +
>  static inline int dw_pcie_host_init(struct dw_pcie_rp *pp)
>  {
>  	return 0;
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 8a882dcd1e4e..042e5845bdd6 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -468,10 +468,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>  		if (rockchip_pcie_link_up(pci)) {
>  			msleep(PCIE_RESET_CONFIG_WAIT_MS);
>  			dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
> -			/* Rescan the bus to enumerate endpoint devices */
> -			pci_lock_rescan_remove();
> -			pci_rescan_bus(pp->bridge->bus);
> -			pci_unlock_rescan_remove();
> +			dw_pcie_handle_link_up_irq(pp);
>  		}
>  	}
>  
> 
> 
> 
> 
> What do you think?
> 
> 
> 
> Kind regards,
> Niklas

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

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On Mon, Nov 10, 2025 at 09:23:02PM +0530, Manivannan Sadhasivam wrote:
> > 
> > Considering what Shawn says, that the switch gets enumerated properly
> > if we simply add a msleep() in ->start_link(), which will be called
> > by dw_pcie_host_init() before pci_host_probe() is called...
> > 
> 
> Yes, that delay probably gives enough time for the link up IRQ to kick in before
> the initial bus scan happens.

I think that the problem is that even for platforms with link up IRQ,
we will always do:
1) dw_pcie_start_link() (if (!dw_pcie_link_up()))
2) pci_host_probe() from dw_pcie_host_init(), this will enumerate the bus
3) pci_rescan_bus() from the Link Up IRQ handler

Thus, in 2, when enumerating the bus, without performing any of the delays
mandated by the PCIe spec, it still seems possible to detect a device (it
must have been really quick to initialize), and to communicate with that
device, however since we have not performed the delays mandated by the spec,
it appears that the device might not yet behave properly.

Hence my suggestion to never call pci_host_probe() in dw_pcie_host_init()
for platforms with Link Up IRQ.

At least for pcie-dw-rockchip.c, we only unmask the Link Up IRQ after
dw_pcie_host_init() has returned, so I think that your theory: that Shawn's
suggested delay causes the Link Up IRQ to kick in before the initial bus
scan, is incorrect. (Since the IRQ should not be able to trigger until
dw_pcie_host_init() has returned.)


> 
> > ...we already have a delay in the link up IRQ handler, before calling
> > pci_rescan_bus().
> > 
> 
> That delay won't help in this case.

Sure, I was just saying that even though Shawn's patch made things work,
it seems incorrect, as we do not want to add "the same delay" that we
already have in the Link Up IRQ. (The delay in the Link Up IRQ should be
the only one.)


> > I think a better solution would be something like:

(snip)

> This solution will work as long as the PCIe device is powered ON before
> start_link(). For CEM and M.2 Key M connectors, the host controller can power
> manage the components. But for other specifications/keys requiring custom power
> management, a separate driver would be needed.
> 
> That's why I suggested using pwrctrl framework as it can satisfy both usecases.
> However, as I said, it needs a bit of rework and I'm close to submitting it.
> 
> But until that gets merged, either we need to revert your link up IRQ change or
> have the below patch. IMO, the revert seems simple.

Using pwrctrl framework once it can handle this use case sounds good to me.

FUKAUMI, could you please send a revert of the two patches?


Kind regards,
Niklas

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

Hi Niklas,

On 11/11/25 04:59, Niklas Cassel wrote:
> On Mon, Nov 10, 2025 at 09:23:02PM +0530, Manivannan Sadhasivam wrote:
>>>
>>> Considering what Shawn says, that the switch gets enumerated properly
>>> if we simply add a msleep() in ->start_link(), which will be called
>>> by dw_pcie_host_init() before pci_host_probe() is called...
>>>
>>
>> Yes, that delay probably gives enough time for the link up IRQ to kick in before
>> the initial bus scan happens.
> 
> I think that the problem is that even for platforms with link up IRQ,
> we will always do:
> 1) dw_pcie_start_link() (if (!dw_pcie_link_up()))
> 2) pci_host_probe() from dw_pcie_host_init(), this will enumerate the bus
> 3) pci_rescan_bus() from the Link Up IRQ handler
> 
> Thus, in 2, when enumerating the bus, without performing any of the delays
> mandated by the PCIe spec, it still seems possible to detect a device (it
> must have been really quick to initialize), and to communicate with that
> device, however since we have not performed the delays mandated by the spec,
> it appears that the device might not yet behave properly.
> 
> Hence my suggestion to never call pci_host_probe() in dw_pcie_host_init()
> for platforms with Link Up IRQ.
> 
> At least for pcie-dw-rockchip.c, we only unmask the Link Up IRQ after
> dw_pcie_host_init() has returned, so I think that your theory: that Shawn's
> suggested delay causes the Link Up IRQ to kick in before the initial bus
> scan, is incorrect. (Since the IRQ should not be able to trigger until
> dw_pcie_host_init() has returned.)
> 
> 
>>
>>> ...we already have a delay in the link up IRQ handler, before calling
>>> pci_rescan_bus().
>>>
>>
>> That delay won't help in this case.
> 
> Sure, I was just saying that even though Shawn's patch made things work,
> it seems incorrect, as we do not want to add "the same delay" that we
> already have in the Link Up IRQ. (The delay in the Link Up IRQ should be
> the only one.)
> 
> 
>>> I think a better solution would be something like:
> 
> (snip)
> 
>> This solution will work as long as the PCIe device is powered ON before
>> start_link(). For CEM and M.2 Key M connectors, the host controller can power
>> manage the components. But for other specifications/keys requiring custom power
>> management, a separate driver would be needed.
>>
>> That's why I suggested using pwrctrl framework as it can satisfy both usecases.
>> However, as I said, it needs a bit of rework and I'm close to submitting it.
>>
>> But until that gets merged, either we need to revert your link up IRQ change or
>> have the below patch. IMO, the revert seems simple.
> 
> Using pwrctrl framework once it can handle this use case sounds good to me.
> 
> FUKAUMI, could you please send a revert of the two patches?

Well, I cannot write a detailed explanation...

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Kind regards,
> Niklas
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[FUKAUMI Naoki]

On 11/11/25 04:59, Niklas Cassel wrote:
> On Mon, Nov 10, 2025 at 09:23:02PM +0530, Manivannan Sadhasivam wrote:
>>>
>>> Considering what Shawn says, that the switch gets enumerated properly
>>> if we simply add a msleep() in ->start_link(), which will be called
>>> by dw_pcie_host_init() before pci_host_probe() is called...
>>>
>>
>> Yes, that delay probably gives enough time for the link up IRQ to kick in before
>> the initial bus scan happens.
> 
> I think that the problem is that even for platforms with link up IRQ,
> we will always do:
> 1) dw_pcie_start_link() (if (!dw_pcie_link_up()))
> 2) pci_host_probe() from dw_pcie_host_init(), this will enumerate the bus
> 3) pci_rescan_bus() from the Link Up IRQ handler
> 
> Thus, in 2, when enumerating the bus, without performing any of the delays
> mandated by the PCIe spec, it still seems possible to detect a device (it
> must have been really quick to initialize), and to communicate with that
> device, however since we have not performed the delays mandated by the spec,
> it appears that the device might not yet behave properly.
> 
> Hence my suggestion to never call pci_host_probe() in dw_pcie_host_init()
> for platforms with Link Up IRQ.
> 
> At least for pcie-dw-rockchip.c, we only unmask the Link Up IRQ after
> dw_pcie_host_init() has returned, so I think that your theory: that Shawn's
> suggested delay causes the Link Up IRQ to kick in before the initial bus
> scan, is incorrect. (Since the IRQ should not be able to trigger until
> dw_pcie_host_init() has returned.)
> 
> 
>>
>>> ...we already have a delay in the link up IRQ handler, before calling
>>> pci_rescan_bus().
>>>
>>
>> That delay won't help in this case.
> 
> Sure, I was just saying that even though Shawn's patch made things work,
> it seems incorrect, as we do not want to add "the same delay" that we
> already have in the Link Up IRQ. (The delay in the Link Up IRQ should be
> the only one.)
> 
> 
>>> I think a better solution would be something like:
> 
> (snip)
> 
>> This solution will work as long as the PCIe device is powered ON before
>> start_link(). For CEM and M.2 Key M connectors, the host controller can power
>> manage the components. But for other specifications/keys requiring custom power
>> management, a separate driver would be needed.
>>
>> That's why I suggested using pwrctrl framework as it can satisfy both usecases.
>> However, as I said, it needs a bit of rework and I'm close to submitting it.
>>
>> But until that gets merged, either we need to revert your link up IRQ change or
>> have the below patch. IMO, the revert seems simple.
> 
> Using pwrctrl framework once it can handle this use case sounds good to me.
> 
> FUKAUMI, could you please send a revert of the two patches?

Leaving the commit message aside, I'm currently testing with a revert of 
the two patches.

Vanilla v6.18-rc5, CONFIG_PCI_DYNAMIC_OF_NODES=y, revert ec9fd499b9c6, 
revert 0e0b45ab5d77.

It works stably on the ROCK 5A. The link speed is 2Gb/s.

The ROCK 5C is unstable. It initially worked with a link speed of 4Gb/s, 
but eventually started showing kernel oops. The dts files for the 5A and 
5C are compatible and interchangeable, but even using the 5A's dts on 
the 5C, the operation remains unstable.

I plan to thoroughly investigate the ROCK 5C's behavior on v6.13, but 
for now, I believe reverting the two patches is the correct action.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Kind regards,
> Niklas
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Shawn Lin]

在 2025/11/11 星期二 10:09, FUKAUMI Naoki 写道:
> On 11/11/25 04:59, Niklas Cassel wrote:

...

> 
> Leaving the commit message aside, I'm currently testing with a revert of 
> the two patches.
> 
> Vanilla v6.18-rc5, CONFIG_PCI_DYNAMIC_OF_NODES=y, revert ec9fd499b9c6, 
> revert 0e0b45ab5d77.
> 
> It works stably on the ROCK 5A. The link speed is 2Gb/s.
> 
> The ROCK 5C is unstable. It initially worked with a link speed of 4Gb/s, 
> but eventually started showing kernel oops. The dts files for the 5A and 
> 5C are compatible and interchangeable, but even using the 5A's dts on 
> the 5C, the operation remains unstable.

The link speed on ROCK 5A is 2Gb/s also means it's downgraded now. Did
ROCK 5A work under the link speed of 4Gb/s before?

In case it's signal integrity relevant, you could enable PCIE_DW_DEBUGFS
and refer to Documentation/ABI/testing/debugfs-dwc-pcie to collect
RASDES info from there.

> 
> I plan to thoroughly investigate the ROCK 5C's behavior on v6.13, but 
> for now, I believe reverting the two patches is the correct action.
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> Kind regards,
>> Niklas
>>
> 
> 
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Niklas Cassel]

On Tue, Nov 11, 2025 at 11:17:23AM +0800, Shawn Lin wrote:
> > 
> > It works stably on the ROCK 5A. The link speed is 2Gb/s.
> > 
> > The ROCK 5C is unstable. It initially worked with a link speed of 4Gb/s,
> > but eventually started showing kernel oops. The dts files for the 5A and
> > 5C are compatible and interchangeable, but even using the 5A's dts on
> > the 5C, the operation remains unstable.
> 
> The link speed on ROCK 5A is 2Gb/s also means it's downgraded now. Did
> ROCK 5A work under the link speed of 4Gb/s before?
> 
> In case it's signal integrity relevant, you could enable PCIE_DW_DEBUGFS
> and refer to Documentation/ABI/testing/debugfs-dwc-pcie to collect
> RASDES info from there.

Just a quick note:
I've noticed that you cannot blindly look at the link speed in dmesg.

E.g. on my ROCK 5B boards, I can occasionally see something like:
[    1.417181] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link

However, if I check the actual link speed with lspci after boot:

# lspci -vvv  -s 0000:01:00.0 | grep LnkSta:
                LnkSta: Speed 8GT/s, Width x4

I can see that the link is actually using the correct speed + number of lanes.


Kind regards,
Niklas

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Shawn Lin]

Hi Mani

在 2025/11/10 星期一 23:53, Manivannan Sadhasivam 写道:
> On Mon, Nov 10, 2025 at 01:34:41PM +0100, Niklas Cassel wrote:
>> On Mon, Nov 10, 2025 at 06:15:33PM +0800, Shawn Lin wrote:
>>>>
>>>> Could you try PCIe 2.0 slot on your board?
>>>
>>> I did, it doesn't work on PCIe 2.0 slot. From the PA, I could see
>>> the link is still in training during pci_host_probe() is called.
>>> Add some delay before pci_rescan_bus() in pcie-dw-rockchip doesn't
>>> help. But the below change should work as we delayed pci_host_probe().
>>>
>>> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>>> @@ -236,6 +236,8 @@ static int rockchip_pcie_start_link(struct dw_pcie *pci)
>>>          msleep(PCIE_T_PVPERL_MS);
>>>          gpiod_set_value_cansleep(rockchip->rst_gpio, 1);
>>>
>>> +       msleep(50);
>>> +
>>>          return 0;
>>>
>>> Otherwise we got:
>>>
>>> [    0.841518] pci_bus 0003:33: busn_res: can not insert [bus 33-31] under
>>> [bus 32-31] (conflicts with (null) [bus 32-31])
>>> [    0.842596] pci_bus 0003:33: busn_res: [bus 33-31] end is updated to 33
>>> [    0.843184] pci_bus 0003:33: busn_res: can not insert [bus 33] under [bus
>>> 32-31] (conflicts with (null) [bus 32-31])
>>> [    0.844120] pci 0003:32:00.0: devices behind bridge are unusable because
>>> [bus 33] cannot be assigned for them
>>> [    0.845229] pci_bus 0003:34: busn_res: can not insert [bus 34-31] under
>>> [bus 32-31] (conflicts with (null) [bus 32-31])
>>> [    0.846309] pci_bus 0003:34: busn_res: [bus 34-31] end is updated to 34
>>> [    0.846898] pci_bus 0003:34: busn_res: can not insert [bus 34] under [bus
>>> 32-31] (conflicts with (null) [bus 32-31])
>>> [    0.847833] pci 0003:32:06.0: devices behind bridge are unusable because
>>> [bus 34] cannot be assigned for them
>>> [    0.848923] pci_bus 0003:35: busn_res: can not insert [bus 35-31] under
>>> [bus 32-31] (conflicts with (null) [bus 32-31])
>>> [    0.850014] pci_bus 0003:35: busn_res: [bus 35-31] end is updated to 35
>>> [    0.850605] pci_bus 0003:35: busn_res: can not insert [bus 35] under [bus
>>> 32-31] (conflicts with (null) [bus 32-31])
>>> [    0.851540] pci 0003:32:0e.0: devices behind bridge are unusable because
>>> [bus 35] cannot be assigned for them
>>> [    0.852424] pci_bus 0003:32: busn_res: [bus 32-31] end is updated to 35
>>> [    0.853028] pci_bus 0003:32: busn_res: can not insert [bus 32-35] under
>>> [bus 31] (conflicts with (null) [bus 31])
>>> [    0.853184] hub 3-0:1.0: USB hub found
>>> [    0.853931] pci 0003:31:00.0: devices behind bridge are unusable because
>>> [bus 32-35] cannot be assigned for them
>>> [    0.854262] hub 3-0:1.0: 1 port detected
>>> [    0.855144] pcieport 0003:30:00.0: bridge has subordinate 31 but max busn
>>> 35
>>> [    0.855722] hub 4-0:1.0: USB hub found
>>> [    0.856109] pci 0003:32:00.0: PCI bridge to [bus 33]
>>> [    0.856939] pci 0003:32:06.0: PCI bridge to [bus 34]
>>> [    0.857133] hub 4-0:1.0: 1 port detected
>>> [    0.857430] pci 0003:32:0e.0: PCI bridge to [bus 35]
>>> [    0.858236] pci 0003:31:00.0: PCI bridge to [bus 32-35]
>>
>> Mani,
>>
>> while I see the idea behind your suggested hack:
>>   
>> +       if (pdev->vendor == 0x1d87 && pdev->device == 0x3588) {
>> +               pdev->is_hotplug_bridge = pdev->is_pciehp = 1;
>> +               return;
>> +       }
>>
>>
>> Considering what Shawn says, that the switch gets enumerated properly
>> if we simply add a msleep() in ->start_link(), which will be called
>> by dw_pcie_host_init() before pci_host_probe() is called...
>>
> 
> Yes, that delay probably gives enough time for the link up IRQ to kick in before
> the initial bus scan happens.
> 
>> ...we already have a delay in the link up IRQ handler, before calling
>> pci_rescan_bus().
>>
> 
> That delay won't help in this case.
> 
>> So, I think that the problem is that we are unconditionally calling
>> pci_host_probe() in dw_pcie_host_init(), even for platforms that have
>> a link-up IRQ.
>>
>>
>> I think a better solution would be something like:
>>
> 
> This solution will work as long as the PCIe device is powered ON before
> start_link(). For CEM and M.2 Key M connectors, the host controller can power
> manage the components. But for other specifications/keys requiring custom power
> management, a separate driver would be needed.
> 

My test environment is a PCIe2.0 x1 CEM slot and a PCIe3.0 x4 CEM slot.
The power supply for slots are controlled by pcie-dw-rockchip, far
earlier than staring to link. From this point, I would expect the result
is consistent, both worked or both failed. But, the result for these two
slots is different, PCIe2.0 slot didn't work but PCIe3.0 slot worked.

After checking with PA, with gpio-input-tigger's help, I could see
PCIe2.0 is still in tranning with thet switch, during pci_host_probe()
is called. This is the only difference I could see then, so as a debug I
add a delay to postpone the pci_host_probe() to make sure the link will
be finished on background.

So this's true if I added the delay, the pci_host_probe（） will see the
switch and the following devices. So your analysis of extented bus makes
sense. But pwrctrl seems helpless here, as we sure power-on the slot
before star_link().

> That's why I suggested using pwrctrl framework as it can satisfy both usecases.
> However, as I said, it needs a bit of rework and I'm close to submitting it.
> 
> But until that gets merged, either we need to revert your link up IRQ change or
> have the below patch. IMO, the revert seems simple.
> 
> - Mani
> 
>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
>> index e92513c5bda5..42d987ddab7d 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>> @@ -565,6 +565,39 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
>>   	return 0;
>>   }
>>   
>> +static int dw_pcie_host_initial_scan(struct dw_pcie_rp *pp)
>> +{
>> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>> +	struct pci_host_bridge *bridge = pp->bridge;
>> +	int ret;
>> +
>> +	ret = pci_host_probe(bridge);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (pp->ops->post_init)
>> +		pp->ops->post_init(pp);
>> +
>> +	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
>> +
>> +	return 0;
>> +}
>> +
>> +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
>> +{
>> +	if (!pp->initial_linkup_irq_done) {
>> +		if (dw_pcie_host_initial_scan(pp)) {
>> +			//TODO: cleanup
>> +		}
>> +		pp->initial_linkup_irq_done = true;
>> +	} else {
>> +		/* Rescan the bus to enumerate endpoint devices */
>> +		pci_lock_rescan_remove();
>> +		pci_rescan_bus(pp->bridge->bus);
>> +		pci_unlock_rescan_remove();
>> +	}
>> +}
>> +
>>   int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>   {
>>   	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>> @@ -672,15 +705,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>   	if (!pp->use_linkup_irq)
>>   		/* Ignore errors, the link may come up later */
>>   		dw_pcie_wait_for_link(pci);
>> -
>> -	ret = pci_host_probe(bridge);
>> -	if (ret)
>> -		goto err_stop_link;
>> -
>> -	if (pp->ops->post_init)
>> -		pp->ops->post_init(pp);
>> -
>> -	dwc_pcie_debugfs_init(pci, DW_PCIE_RC_TYPE);
>> +	else
>> +		/*
>> +		 * For platforms with Link Up IRQ, initial scan will be done
>> +		 * on first Link Up IRQ.
>> +		 */
>> +		if (dw_pcie_host_initial_scan(pp))
>> +			goto err_stop_link;
>>   
>>   	return 0;
>>   
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
>> index e995f692a1ec..a31bd93490dc 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.h
>> +++ b/drivers/pci/controller/dwc/pcie-designware.h
>> @@ -427,6 +427,7 @@ struct dw_pcie_rp {
>>   	int			msg_atu_index;
>>   	struct resource		*msg_res;
>>   	bool			use_linkup_irq;
>> +	bool			initial_linkup_irq_done;
>>   	struct pci_eq_presets	presets;
>>   	struct pci_config_window *cfg;
>>   	bool			ecam_enabled;
>> @@ -807,6 +808,7 @@ void dw_pcie_msi_init(struct dw_pcie_rp *pp);
>>   int dw_pcie_msi_host_init(struct dw_pcie_rp *pp);
>>   void dw_pcie_free_msi(struct dw_pcie_rp *pp);
>>   int dw_pcie_setup_rc(struct dw_pcie_rp *pp);
>> +void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp);
>>   int dw_pcie_host_init(struct dw_pcie_rp *pp);
>>   void dw_pcie_host_deinit(struct dw_pcie_rp *pp);
>>   int dw_pcie_allocate_domains(struct dw_pcie_rp *pp);
>> @@ -844,6 +846,9 @@ static inline int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
>>   	return 0;
>>   }
>>   
>> +static inline void dw_pcie_handle_link_up_irq(struct dw_pcie_rp *pp)
>> +{ }
>> +
>>   static inline int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>   {
>>   	return 0;
>> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> index 8a882dcd1e4e..042e5845bdd6 100644
>> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> @@ -468,10 +468,7 @@ static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
>>   		if (rockchip_pcie_link_up(pci)) {
>>   			msleep(PCIE_RESET_CONFIG_WAIT_MS);
>>   			dev_dbg(dev, "Received Link up event. Starting enumeration!\n");
>> -			/* Rescan the bus to enumerate endpoint devices */
>> -			pci_lock_rescan_remove();
>> -			pci_rescan_bus(pp->bridge->bus);
>> -			pci_unlock_rescan_remove();
>> +			dw_pcie_handle_link_up_irq(pp);
>>   		}
>>   	}
>>   
>>
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Kind regards,
>> Niklas
> 

Re: [RESEND] Re: [PATCH] PCI: dw-rockchip: Skip waiting for link up

[Manivannan Sadhasivam]

On Mon, Nov 10, 2025 at 08:26:56AM +0900, FUKAUMI Naoki wrote:
> (RESEND: fix mani's email address)
> 

Thanks for looping me in! My Linaro email is not functional anymore.

> Hi Niklas,
> 
> On 11/9/25 21:28, Niklas Cassel wrote:
> > On Sun, Nov 09, 2025 at 01:42:23PM +0900, FUKAUMI Naoki wrote:
> > > Hi Niklas,
> > > 
> > > On 11/8/25 22:27, Niklas Cassel wrote:
> > > (snip)> (And btw. please test with the latest 6.18-rc, as, from experience,
> > > the
> > > > ASPM problems in earlier RCs can result in some weird problems that are
> > > > not immediately deduced to be caused by the ASPM enablement.)
> > > 
> > > Here is dmesg from v6.18-rc4:
> > >   https://gist.github.com/RadxaNaoki/40e1d049bff4f1d2d4773a5ba0ed9dff
> > 
> > Same problem as before:
> > [    1.732538] pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.732645] pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> > [    1.732651] pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.732661] pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> > [    1.732840] pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.732947] pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> > [    1.732952] pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.732962] pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> > [    1.733134] pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.733246] pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> > [    1.733255] pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.733266] pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> > [    1.733438] pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.733544] pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> > [    1.733550] pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> > [    1.733560] pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> > [    1.733571] pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> > [    1.733575] pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> > [    1.733585] pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> > [    1.733596] pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> > 
> > 
> > Seems like the ASM2806 switch, for some reason, is not ready.
> > 
> > One change that Diederik pointed out is that in the "good" case,
> > the link is always in Gen1 speed.
> > 
> > Perhaps you could build with CONFIG_PCI_QUIRKS=y and try this patch:
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 214ed060ca1b..ac134d95a97f 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -96,6 +96,7 @@ int pcie_failed_link_retrain(struct pci_dev *dev)
> >   {
> >   	static const struct pci_device_id ids[] = {
> >   		{ PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
> > +		{ PCI_VDEVICE(ASMEDIA, 0x2806) }, /* ASMedia ASM2806 */
> >   		{}
> >   	};
> >   	u16 lnksta, lnkctl2;
> 
> It doesn't help with either probing behind the bridge or the link speed.
> 
> > If that does not work, perhaps you could try this patch
> > (assuming that all Rock 5C:s have a ASM2806 on pcie2x1l2):
> 
> ROCK 5C has a PCIe FPC connector and I'm using Dual 2.5G Router HAT.
>  https://radxa.com/products/rock5/5c#techspec
>  https://radxa.com/products/accessories/dual-2-5g-router-hat
> 
> Regarding the link speed, I initially suspected the FPC connector and/or
> cable might be the issue. However, I tried the Dual 2.5G Router HAT with the
> ROCK 5A (which uses a different cable), and I got the same result.
> 
> BTW, the link speed varies between 2Gb/s and 4Gb/s depending on the reboot.
> (with or without quirk)
> 

From the dmesg log, it looks like the issue is most probably due to bus number
assignment for the Root Port. During the initial bus scan, the PCI core will
assign the subordinate bus number (max bus number behind the PCI bridge) of the
PCI bridge based on the available busses scanned behind the bridge. Before the
link up IRQ patch, I guess the PCIe switch connected to the Root Port gets
enumerated during dw_pcie_wait_for_link() itself i.e., before the PCI core
starts the bus scan with a call to pci_host_probe(). So the switch appears when
the PCI core starts scanning the bus and the subordinate bus number gets
assigned correctly as the PCI core could see the available busses behind the
Root Port.

This could be confirmed from the timing of the success log:

[    1.875690] pci 0004:40:00.0: bridge configuration invalid ([bus 01-ff]), reconfiguring
[    1.876543] pci 0004:41:00.0: [1b21:2806] type 01 class 0x060400 PCIe Switch Upstream Port

Time difference is 853ms.

But with the link up IRQ patch, dw_pcie_wait_for_link() is skipped and the
device appears *after* the initial bus scan by the PCI core.

From the failure log:

[    1.392130] pci 0004:40:00.0: PCI bridge to [bus 41]
[    1.392607] pci_bus 0004:40: resource 4 [io  0x0000-0xfffff]
[    1.393103] pci_bus 0004:40: resource 5 [mem 0xf4200000-0xf4ffffff]
[    1.393657] pci_bus 0004:40: resource 6 [mem 0xa00000000-0xa3fffffff]
[    1.412296] pci 0004:41:00.0: [1b21:2806] type 01 class 0x060400 PCIe Switch Upstream Port

Note the timing and also the PCI bridge resource assignment.

So during the initial scan, PCI core doesn't see the switch and since the Root
Port is not hot plug capable (I'm assuming that's the case), the secondary bus
number gets assigned as the subordinate bus number (41). This means, the PCI
core assumes that only one bus will appear behind the Root Port since the Root
Port is not hot plug capable. This will work perfectly fine for PCIe endpoints
connected to the Root Port, since they don't extend the bus. But if you connect
a PCIe switch, then you'll see the issue as the downstream busses starts showing
up and PCI core doesn't extend the subordinate bus number after initial scan
during boot.

This is also confirmed by the below log in failure case:

[    1.478814] pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46

If you try the below hack, you might get the switch working:

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index c83e75a0ec12..01afb5b23eba 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1701,6 +1701,11 @@ void set_pcie_hotplug_bridge(struct pci_dev *pdev)
 {
        u32 reg32;
 
+       if (pdev->vendor == 0x1d87 && pdev->device == 0x3588) {
+               pdev->is_hotplug_bridge = pdev->is_pciehp = 1;
+               return;
+       }
+
        pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, &reg32);
        if (reg32 & PCI_EXP_SLTCAP_HPC)
                pdev->is_hotplug_bridge = pdev->is_pciehp = 1;

The above diff just fakes the Root Port as hot plug capable to the PCI core so
that more subordinate bus numbers gets assigned to it in the anticipation of
more busses showing up post scan.

If the above works, then you should make sure that the switch is powered and the
link to be up before the initial bus scan. The proper way to do this would be by
modeling your switch power resources in devicetree and relying on the
CONFIG_PWRCTRL_SLOT driver to power it up and scan the bus. But this driver
needs some extra work to satisfy your needs and I'm going to post a series in
the coming weeks for that.

Until then, I'd suggest to revert the link up IRQ patch as a stop-gap solution.

NOTE: As Niklas rightly pointed out, this issue also affects the Qcom platforms
which follows the same code pattern and also other platforms as well. For Qcom,
we are relying on the upcoming pwrctrl fixes to properly enumerate the PCIe
switches in upstream.

- Mani

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