[PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Niklas Cassel]

Revert all patches related to pcie-designware Root Complex Link Up IRQ
support.

While this fake hotplugging was a nice idea, it has shown that this feature
does not handle PCIe switches correctly:
pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46

During the initial scan, PCI core doesn't see the switch and since the Root
Port is not hot plug capable, the secondary bus number gets assigned as the
subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
since they don't extend the bus. However, if a PCIe switch is connected,
then there is a problem when the downstream busses starts showing up and
the PCI core doesn't extend the subordinate bus number after initial scan
during boot.

The long term plan is to migrate this driver to the pwrctrl framework,
once it adds proper support for powering up and enumerating PCIe switches.

Niklas Cassel (6):
  Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link
    Up"
  Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up
    IRQ"
  Revert "PCI: qcom: Don't wait for link if we can detect Link Up"
  Revert "PCI: qcom: Enable MSI interrupts together with Link up if
    'Global IRQ' is supported"
  Revert "PCI: qcom: Enumerate endpoints based on Link up event in
    'global_irq' interrupt"
  Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up
    event"

 .../pci/controller/dwc/pcie-designware-host.c | 10 +--
 drivers/pci/controller/dwc/pcie-designware.h  |  1 -
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 60 +-----------------
 drivers/pci/controller/dwc/pcie-qcom.c        | 63 +------------------
 4 files changed, 6 insertions(+), 128 deletions(-)

-- 
2.51.1

[PATCH 1/6] Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up"

[Niklas Cassel]

This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42.

While this fake hotplugging was a nice idea, it has shown that this feature
does not handle PCIe switches correctly:
pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46

During the initial scan, PCI core doesn't see the switch and since the Root
Port is not hot plug capable, the secondary bus number gets assigned as the
subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
since they don't extend the bus. However, if a PCIe switch is connected,
then there is a problem when the downstream busses starts showing up and
the PCI core doesn't extend the subordinate bus number after initial scan
during boot.

The long term plan is to migrate this driver to the pwrctrl framework,
once it adds proper support for powering up and enumerating PCIe switches.

Cc: stable@vger.kernel.org
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 3e2752c7dd09..07378ececd88 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -541,7 +541,6 @@ static int rockchip_pcie_configure_rc(struct platform_device *pdev,
 
 	pp = &rockchip->pci.pp;
 	pp->ops = &rockchip_pcie_host_ops;
-	pp->use_linkup_irq = true;
 
 	ret = dw_pcie_host_init(pp);
 	if (ret) {
-- 
2.51.1

[PATCH 2/6] Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"

[Niklas Cassel]

This reverts commit 0e0b45ab5d770a748487ba0ae8f77d1fb0f0de3e.

While this fake hotplugging was a nice idea, it has shown that this feature
does not handle PCIe switches correctly:
pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46

During the initial scan, PCI core doesn't see the switch and since the Root
Port is not hot plug capable, the secondary bus number gets assigned as the
subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
since they don't extend the bus. However, if a PCIe switch is connected,
then there is a problem when the downstream busses starts showing up and
the PCI core doesn't extend the subordinate bus number after initial scan
during boot.

The long term plan is to migrate this driver to the pwrctrl framework,
once it adds proper support for powering up and enumerating PCIe switches.

Cc: stable@vger.kernel.org
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/pci/controller/dwc/pcie-dw-rockchip.c | 59 +------------------
 1 file changed, 3 insertions(+), 56 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 07378ececd88..7eceec8c9c83 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -448,34 +448,6 @@ static const struct dw_pcie_ops dw_pcie_ops = {
 	.stop_link = rockchip_pcie_stop_link,
 };
 
-static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
-{
-	struct rockchip_pcie *rockchip = arg;
-	struct dw_pcie *pci = &rockchip->pci;
-	struct dw_pcie_rp *pp = &pci->pp;
-	struct device *dev = pci->dev;
-	u32 reg;
-
-	reg = rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_INTR_STATUS_MISC);
-	rockchip_pcie_writel_apb(rockchip, reg, PCIE_CLIENT_INTR_STATUS_MISC);
-
-	dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg);
-	dev_dbg(dev, "LTSSM_STATUS: %#x\n", rockchip_pcie_get_ltssm(rockchip));
-
-	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_rescan_bus(pp->bridge->bus);
-			pci_unlock_rescan_remove();
-		}
-	}
-
-	return IRQ_HANDLED;
-}
-
 static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg)
 {
 	struct rockchip_pcie *rockchip = arg;
@@ -508,29 +480,14 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg)
 	return IRQ_HANDLED;
 }
 
-static int rockchip_pcie_configure_rc(struct platform_device *pdev,
-				      struct rockchip_pcie *rockchip)
+static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
 {
-	struct device *dev = &pdev->dev;
 	struct dw_pcie_rp *pp;
-	int irq, ret;
 	u32 val;
 
 	if (!IS_ENABLED(CONFIG_PCIE_ROCKCHIP_DW_HOST))
 		return -ENODEV;
 
-	irq = platform_get_irq_byname(pdev, "sys");
-	if (irq < 0)
-		return irq;
-
-	ret = devm_request_threaded_irq(dev, irq, NULL,
-					rockchip_pcie_rc_sys_irq_thread,
-					IRQF_ONESHOT, "pcie-sys-rc", rockchip);
-	if (ret) {
-		dev_err(dev, "failed to request PCIe sys IRQ\n");
-		return ret;
-	}
-
 	/* LTSSM enable control mode */
 	val = FIELD_PREP_WM16(PCIE_LTSSM_ENABLE_ENHANCE, 1);
 	rockchip_pcie_writel_apb(rockchip, val, PCIE_CLIENT_HOT_RESET_CTRL);
@@ -542,17 +499,7 @@ static int rockchip_pcie_configure_rc(struct platform_device *pdev,
 	pp = &rockchip->pci.pp;
 	pp->ops = &rockchip_pcie_host_ops;
 
-	ret = dw_pcie_host_init(pp);
-	if (ret) {
-		dev_err(dev, "failed to initialize host\n");
-		return ret;
-	}
-
-	/* unmask DLL up/down indicator */
-	val = FIELD_PREP_WM16(PCIE_RDLH_LINK_UP_CHGED, 0);
-	rockchip_pcie_writel_apb(rockchip, val, PCIE_CLIENT_INTR_MASK_MISC);
-
-	return ret;
+	return dw_pcie_host_init(pp);
 }
 
 static int rockchip_pcie_configure_ep(struct platform_device *pdev,
@@ -678,7 +625,7 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 
 	switch (data->mode) {
 	case DW_PCIE_RC_TYPE:
-		ret = rockchip_pcie_configure_rc(pdev, rockchip);
+		ret = rockchip_pcie_configure_rc(rockchip);
 		if (ret)
 			goto deinit_clk;
 		break;
-- 
2.51.1

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Niklas Cassel]

Hello Lukas,

On Tue, Nov 11, 2025 at 12:08:59PM +0100, Lukas Wunner wrote:
> On Tue, Nov 11, 2025 at 11:51:00AM +0100, Niklas Cassel wrote:
> > Revert all patches related to pcie-designware Root Complex Link Up IRQ
> > support.
> > 
> > While this fake hotplugging was a nice idea, it has shown that this feature
> > does not handle PCIe switches correctly:
> [...]
> > During the initial scan, PCI core doesn't see the switch and since the Root
> > Port is not hot plug capable, the secondary bus number gets assigned as the
> > subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
> > since they don't extend the bus. However, if a PCIe switch is connected,
> > then there is a problem when the downstream busses starts showing up and
> > the PCI core doesn't extend the subordinate bus number after initial scan
> > during boot.
> 
> In principle it is possible to set the is_hotplug_bridge flag on the
> bridge to force allocation of more buses.  We've already got a quirk
> to set the flag on a Conventional PCI bridge whose hotplug capability
> cannot be discovered otherwise (see quirk_hotplug_bridge() in
> drivers/pci/quirks.c).

While pdev->is_hotplug_bridge was also mentioned by Mani, he seems to
prefer a revert + eventual migration to pwrctrl framework:
https://lore.kernel.org/linux-pci/4f4wsgf56eublizg63fz6xmdjixesalb2q3rxetphd55jpqqju@zfyzsxfgiyim/
https://lore.kernel.org/linux-pci/2n3wamm3txxc6xbmvf3nnrvaqpgsck3w4a6omxnhex3mqeujib@2tb4svn5d3z6/


Kind regards,
Niklas

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Shawn Lin]

在 2025/11/11 星期二 18:51, Niklas Cassel 写道:
> Revert all patches related to pcie-designware Root Complex Link Up IRQ
> support.
> 
> While this fake hotplugging was a nice idea, it has shown that this feature
> does not handle PCIe switches correctly:
> pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> 
> During the initial scan, PCI core doesn't see the switch and since the Root
> Port is not hot plug capable, the secondary bus number gets assigned as the
> subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
> since they don't extend the bus. However, if a PCIe switch is connected,
> then there is a problem when the downstream busses starts showing up and
> the PCI core doesn't extend the subordinate bus number after initial scan
> during boot.
> 
> The long term plan is to migrate this driver to the pwrctrl framework,
> once it adds proper support for powering up and enumerating PCIe switches.

For pcie-dw-rockchip

Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>

> 
> Niklas Cassel (6):
>    Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link
>      Up"
>    Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up
>      IRQ"
>    Revert "PCI: qcom: Don't wait for link if we can detect Link Up"
>    Revert "PCI: qcom: Enable MSI interrupts together with Link up if
>      'Global IRQ' is supported"
>    Revert "PCI: qcom: Enumerate endpoints based on Link up event in
>      'global_irq' interrupt"
>    Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up
>      event"
> 
>   .../pci/controller/dwc/pcie-designware-host.c | 10 +--
>   drivers/pci/controller/dwc/pcie-designware.h  |  1 -
>   drivers/pci/controller/dwc/pcie-dw-rockchip.c | 60 +-----------------
>   drivers/pci/controller/dwc/pcie-qcom.c        | 63 +------------------
>   4 files changed, 6 insertions(+), 128 deletions(-)
> 

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Manivannan Sadhasivam]

On Tue, Nov 11, 2025 at 12:08:59PM +0100, Lukas Wunner wrote:
> On Tue, Nov 11, 2025 at 11:51:00AM +0100, Niklas Cassel wrote:
> > Revert all patches related to pcie-designware Root Complex Link Up IRQ
> > support.
> > 
> > While this fake hotplugging was a nice idea, it has shown that this feature
> > does not handle PCIe switches correctly:
> [...]
> > During the initial scan, PCI core doesn't see the switch and since the Root
> > Port is not hot plug capable, the secondary bus number gets assigned as the
> > subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
> > since they don't extend the bus. However, if a PCIe switch is connected,
> > then there is a problem when the downstream busses starts showing up and
> > the PCI core doesn't extend the subordinate bus number after initial scan
> > during boot.
> 
> In principle it is possible to set the is_hotplug_bridge flag on the
> bridge to force allocation of more buses.  We've already got a quirk
> to set the flag on a Conventional PCI bridge whose hotplug capability
> cannot be discovered otherwise (see quirk_hotplug_bridge() in
> drivers/pci/quirks.c).

But here, the bridges are not hotplug capable at all. They do not support the
PCI Hot-Plug Specification. So setting the flag would be incorrect.

- Mani

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

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Niklas Cassel]

On Tue, Nov 11, 2025 at 11:51:00AM +0100, Niklas Cassel wrote:
> Revert all patches related to pcie-designware Root Complex Link Up IRQ
> support.
> 
> While this fake hotplugging was a nice idea, it has shown that this feature
> does not handle PCIe switches correctly:
> pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> 
> During the initial scan, PCI core doesn't see the switch and since the Root
> Port is not hot plug capable, the secondary bus number gets assigned as the
> subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
> since they don't extend the bus. However, if a PCIe switch is connected,
> then there is a problem when the downstream busses starts showing up and
> the PCI core doesn't extend the subordinate bus number after initial scan
> during boot.
> 
> The long term plan is to migrate this driver to the pwrctrl framework,
> once it adds proper support for powering up and enumerating PCIe switches.


Hello PCI maintainers,

Merge window is opening soon,
what is the status of this series?


Kind regards,
Niklas

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Manivannan Sadhasivam]

On Tue, Nov 11, 2025 at 11:51:00AM +0100, Niklas Cassel wrote:
> Revert all patches related to pcie-designware Root Complex Link Up IRQ
> support.
> 
> While this fake hotplugging was a nice idea, it has shown that this feature
> does not handle PCIe switches correctly:
> pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> 
> During the initial scan, PCI core doesn't see the switch and since the Root
> Port is not hot plug capable, the secondary bus number gets assigned as the
> subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
> since they don't extend the bus. However, if a PCIe switch is connected,
> then there is a problem when the downstream busses starts showing up and
> the PCI core doesn't extend the subordinate bus number after initial scan
> during boot.
> 
> The long term plan is to migrate this driver to the pwrctrl framework,
> once it adds proper support for powering up and enumerating PCIe switches.
> 

While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
seen a case where people connect a random PCIe switch and saw failures. Most of
the Qcom usecases were around the M.2 and other proprietary connectors. There is
only one in-house PCIe switch that is being actively used in our products, but
so far, none of the bootloaders have turned them ON before kernel booting. So
kernel relies on the newly merged pwrctrl driver to do the job. Even though it
also suffers from the same resource allocation issue, this series won't help in
any way as pwrctrl core performs rescan after the switch power ON, and by that
time, it will be very late anyway.

So I'm happy to take the rockhip patches from this series as they fix the real
issue that people have reported. But once the pwrctrl rework series gets merged,
and the rockchip drivers support them, we can bring back the reverted changes.

- Mani

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

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Niklas Cassel]

On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
> While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
> expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
> seen a case where people connect a random PCIe switch and saw failures. Most of
> the Qcom usecases were around the M.2 and other proprietary connectors. There is
> only one in-house PCIe switch that is being actively used in our products, but
> so far, none of the bootloaders have turned them ON before kernel booting. So
> kernel relies on the newly merged pwrctrl driver to do the job. Even though it
> also suffers from the same resource allocation issue, this series won't help in
> any way as pwrctrl core performs rescan after the switch power ON, and by that
> time, it will be very late anyway.
> 
> So I'm happy to take the rockhip patches from this series as they fix the real
> issue that people have reported. But once the pwrctrl rework series gets merged,
> and the rockchip drivers support them, we can bring back the reverted changes.

FUKAUMI Naoki, just to confirm:

Neither my suggested approach:
https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/

nor Shawn's suggested approach:
https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/

worked for you?


If so, I don't see many alternative but for Mani to apply patch 1 and
patch 2 from this series.


Kind regards,
Niklas

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[FUKAUMI Naoki]

Hi Niklas,

I apologize for the delayed response.

On 11/24/25 23:02, Niklas Cassel wrote:
> On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
>> While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
>> expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
>> seen a case where people connect a random PCIe switch and saw failures. Most of
>> the Qcom usecases were around the M.2 and other proprietary connectors. There is
>> only one in-house PCIe switch that is being actively used in our products, but
>> so far, none of the bootloaders have turned them ON before kernel booting. So
>> kernel relies on the newly merged pwrctrl driver to do the job. Even though it
>> also suffers from the same resource allocation issue, this series won't help in
>> any way as pwrctrl core performs rescan after the switch power ON, and by that
>> time, it will be very late anyway.
>>
>> So I'm happy to take the rockhip patches from this series as they fix the real
>> issue that people have reported. But once the pwrctrl rework series gets merged,
>> and the rockchip drivers support them, we can bring back the reverted changes.
> 
> FUKAUMI Naoki, just to confirm:
> 
> Neither my suggested approach:
> https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
> 
> nor Shawn's suggested approach:
> https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/
> 
> worked for you?

Yes, I re-tested the two methods mentioned above, separately, on 
v6.18-rc7, but neither of them resolved the issue in my environment 
(ROCK 5C + ASM2806).

> If so, I don't see many alternative but for Mani to apply patch 1 and
> patch 2 from this series.

I believe applying patch 1 and patch 2 should be sufficient.

----

Incidentally, (probably) while applying patch 1 and patch 2, I have 
encountered the following issue several times:

[    1.709614] pcieport 0004:41:00.0: of_irq_parse_pci: failed with rc=134
[    1.710208] pcieport 0004:41:00.0: Unable to change power state from 
D3cold to D0, device inaccessible

I am still investigating this matter, and the conditions under which it 
occurs are currently unknown.

Best regards,

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

> Kind regards,
> Niklas
> 

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Manivannan Sadhasivam]

On Wed, Nov 26, 2025 at 10:30:06PM +0900, FUKAUMI Naoki wrote:
> Hi Niklas,
> 
> I apologize for the delayed response.
> 
> On 11/24/25 23:02, Niklas Cassel wrote:
> > On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
> > > While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
> > > expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
> > > seen a case where people connect a random PCIe switch and saw failures. Most of
> > > the Qcom usecases were around the M.2 and other proprietary connectors. There is
> > > only one in-house PCIe switch that is being actively used in our products, but
> > > so far, none of the bootloaders have turned them ON before kernel booting. So
> > > kernel relies on the newly merged pwrctrl driver to do the job. Even though it
> > > also suffers from the same resource allocation issue, this series won't help in
> > > any way as pwrctrl core performs rescan after the switch power ON, and by that
> > > time, it will be very late anyway.
> > > 
> > > So I'm happy to take the rockhip patches from this series as they fix the real
> > > issue that people have reported. But once the pwrctrl rework series gets merged,
> > > and the rockchip drivers support them, we can bring back the reverted changes.
> > 
> > FUKAUMI Naoki, just to confirm:
> > 
> > Neither my suggested approach:
> > https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
> > 
> > nor Shawn's suggested approach:
> > https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/
> > 
> > worked for you?
> 
> Yes, I re-tested the two methods mentioned above, separately, on v6.18-rc7,
> but neither of them resolved the issue in my environment (ROCK 5C +
> ASM2806).
> 
> > If so, I don't see many alternative but for Mani to apply patch 1 and
> > patch 2 from this series.
> 
> I believe applying patch 1 and patch 2 should be sufficient.
> 
> ----
> 
> Incidentally, (probably) while applying patch 1 and patch 2, I have
> encountered the following issue several times:
>

Do you see the below issue *after* applying the patches? I don't know how to
interpret "while applying".
 
> [    1.709614] pcieport 0004:41:00.0: of_irq_parse_pci: failed with rc=134
> [    1.710208] pcieport 0004:41:00.0: Unable to change power state from
> D3cold to D0, device inaccessible
> 

Looks like the device was seen during bus scan, but then it went down
afterwards.

- Mani

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

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[FUKAUMI Naoki]

Hi Mani,

On 11/26/25 22:54, Manivannan Sadhasivam wrote:
> On Wed, Nov 26, 2025 at 10:30:06PM +0900, FUKAUMI Naoki wrote:
>> Hi Niklas,
>>
>> I apologize for the delayed response.
>>
>> On 11/24/25 23:02, Niklas Cassel wrote:
>>> On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
>>>> While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
>>>> expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
>>>> seen a case where people connect a random PCIe switch and saw failures. Most of
>>>> the Qcom usecases were around the M.2 and other proprietary connectors. There is
>>>> only one in-house PCIe switch that is being actively used in our products, but
>>>> so far, none of the bootloaders have turned them ON before kernel booting. So
>>>> kernel relies on the newly merged pwrctrl driver to do the job. Even though it
>>>> also suffers from the same resource allocation issue, this series won't help in
>>>> any way as pwrctrl core performs rescan after the switch power ON, and by that
>>>> time, it will be very late anyway.
>>>>
>>>> So I'm happy to take the rockhip patches from this series as they fix the real
>>>> issue that people have reported. But once the pwrctrl rework series gets merged,
>>>> and the rockchip drivers support them, we can bring back the reverted changes.
>>>
>>> FUKAUMI Naoki, just to confirm:
>>>
>>> Neither my suggested approach:
>>> https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
>>>
>>> nor Shawn's suggested approach:
>>> https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/
>>>
>>> worked for you?
>>
>> Yes, I re-tested the two methods mentioned above, separately, on v6.18-rc7,
>> but neither of them resolved the issue in my environment (ROCK 5C +
>> ASM2806).
>>
>>> If so, I don't see many alternative but for Mani to apply patch 1 and
>>> patch 2 from this series.
>>
>> I believe applying patch 1 and patch 2 should be sufficient.
>>
>> ----
>>
>> Incidentally, (probably) while applying patch 1 and patch 2, I have
>> encountered the following issue several times:
>>
> 
> Do you see the below issue *after* applying the patches? I don't know how to
> interpret "while applying".
>   
>> [    1.709614] pcieport 0004:41:00.0: of_irq_parse_pci: failed with rc=134
>> [    1.710208] pcieport 0004:41:00.0: Unable to change power state from
>> D3cold to D0, device inaccessible
>>
> 
> Looks like the device was seen during bus scan, but then it went down
> afterwards.

Sorry, I meant "after". But I guess it occurred with vanilla kernel in 
the past:

  https://lore.kernel.org/linux-pci/4487DA40249CC821+19232169-a096-4737-bc6a-5cec9592d65f@radxa.com/
  https://gist.github.com/RadxaNaoki/b42252ce3209d9f6bc2d4c90c71956ae#file-gistfile1-txt-L551

This time I unset CONFIG_PCI_DYNAMIC_OF_NODES, but this error occurred 
at same location when kernel oops occurred.

It might be a problem with ROCK 5C, (or *my* ROCK 5C), so I'll test 
again with ROCK 5B.

Best regards,

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

> - Mani
> 

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[FUKAUMI Naoki]

Hi all,

I'm very sorry, but my ROCK 5C appears to be unreliable. (It worked fine 
with vanilla v6.13, so I thought it was fine.)

I replaced it with another 5C (Lite), and now every method (Niklas's 
patch, Shawn's patch, and applying patch 1 and 2) seems to work.

Testing with the 5C Lite is still not enough, further testing is 
required, but I will probably need to revise my test results.

(Those seem to work on ROCK 5A/5B, but they also need further testing.)

I truly apologize for my unreliable testing.

Best regards,

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

On 11/26/25 22:30, FUKAUMI Naoki wrote:
> Hi Niklas,
> 
> I apologize for the delayed response.
> 
> On 11/24/25 23:02, Niklas Cassel wrote:
>> On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
>>> While I suggested to revert the link up IRQ patch for rockchip 
>>> earlier, I didn't
>>> expect to drop the support for Qcom. The reason is, on Qcom SoCs, we 
>>> have not
>>> seen a case where people connect a random PCIe switch and saw 
>>> failures. Most of
>>> the Qcom usecases were around the M.2 and other proprietary 
>>> connectors. There is
>>> only one in-house PCIe switch that is being actively used in our 
>>> products, but
>>> so far, none of the bootloaders have turned them ON before kernel 
>>> booting. So
>>> kernel relies on the newly merged pwrctrl driver to do the job. Even 
>>> though it
>>> also suffers from the same resource allocation issue, this series 
>>> won't help in
>>> any way as pwrctrl core performs rescan after the switch power ON, 
>>> and by that
>>> time, it will be very late anyway.
>>>
>>> So I'm happy to take the rockhip patches from this series as they fix 
>>> the real
>>> issue that people have reported. But once the pwrctrl rework series 
>>> gets merged,
>>> and the rockchip drivers support them, we can bring back the reverted 
>>> changes.
>>
>> FUKAUMI Naoki, just to confirm:
>>
>> Neither my suggested approach:
>> https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
>>
>> nor Shawn's suggested approach:
>> https://lore.kernel.org/linux-pci/dc932773-af5b-4af7- 
>> a0d0-8cc72dfbd3c7@rock-chips.com/
>>
>> worked for you?
> 
> Yes, I re-tested the two methods mentioned above, separately, on v6.18- 
> rc7, but neither of them resolved the issue in my environment (ROCK 5C + 
> ASM2806).
> 
>> If so, I don't see many alternative but for Mani to apply patch 1 and
>> patch 2 from this series.
> 
> I believe applying patch 1 and patch 2 should be sufficient.
> 
> ----
> 
> Incidentally, (probably) while applying patch 1 and patch 2, I have 
> encountered the following issue several times:
> 
> [    1.709614] pcieport 0004:41:00.0: of_irq_parse_pci: failed with rc=134
> [    1.710208] pcieport 0004:41:00.0: Unable to change power state from 
> D3cold to D0, device inaccessible
> 
> I am still investigating this matter, and the conditions under which it 
> occurs are currently unknown.
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> Kind regards,
>> Niklas
>>
> 

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Niklas Cassel]

Hello FUKAUMI Naoki,

On Thu, Nov 27, 2025 at 04:34:53PM +0900, FUKAUMI Naoki wrote:
> Hi all,
> 
> I'm very sorry, but my ROCK 5C appears to be unreliable. (It worked fine
> with vanilla v6.13, so I thought it was fine.)
> 
> I replaced it with another 5C (Lite), and now every method (Niklas's patch,
> Shawn's patch, and applying patch 1 and 2) seems to work.

Could you please give us some more information.

Does the Rock 5C Lite have a PCIe switch?

Does Rock 5C Lite work fine with the current code in mainline?
(i.e. with bus enumeration when Link Up IRQ is triggered).


Kind regards,
Niklas

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[FUKAUMI Naoki]

Hi Niklas,

On 11/27/25 16:43, Niklas Cassel wrote:
> Hello FUKAUMI Naoki,
> 
> On Thu, Nov 27, 2025 at 04:34:53PM +0900, FUKAUMI Naoki wrote:
>> Hi all,
>>
>> I'm very sorry, but my ROCK 5C appears to be unreliable. (It worked fine
>> with vanilla v6.13, so I thought it was fine.)
>>
>> I replaced it with another 5C (Lite), and now every method (Niklas's patch,
>> Shawn's patch, and applying patch 1 and 2) seems to work.
> 
> Could you please give us some more information.

Sorry for the confusion.

> Does the Rock 5C Lite have a PCIe switch?

ROCK 5C and 5C Lite use the same board design, only SoC is different, 
but there is no difference regarding PCIe functionality.

They have a PCIe 2.1 connector, and I've been testing a HAT with ASM2806 
via PCIe 2.1 connector.

> Does Rock 5C Lite work fine with the current code in mainline?
> (i.e. with bus enumeration when Link Up IRQ is triggered).

No, bus enumeration behind ASM2806 on ROCK 5C Lite (and any other 
RK358x-based boards I have) is not working with vanilla kernel.

Best regards,

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

> Kind regards,
> Niklas
> 

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[FUKAUMI Naoki]

Hi Niklas,

On 11/24/25 23:02, Niklas Cassel wrote:
> On Mon, Nov 24, 2025 at 06:07:44PM +0530, Manivannan Sadhasivam wrote:
>> While I suggested to revert the link up IRQ patch for rockchip earlier, I didn't
>> expect to drop the support for Qcom. The reason is, on Qcom SoCs, we have not
>> seen a case where people connect a random PCIe switch and saw failures. Most of
>> the Qcom usecases were around the M.2 and other proprietary connectors. There is
>> only one in-house PCIe switch that is being actively used in our products, but
>> so far, none of the bootloaders have turned them ON before kernel booting. So
>> kernel relies on the newly merged pwrctrl driver to do the job. Even though it
>> also suffers from the same resource allocation issue, this series won't help in
>> any way as pwrctrl core performs rescan after the switch power ON, and by that
>> time, it will be very late anyway.
>>
>> So I'm happy to take the rockhip patches from this series as they fix the real
>> issue that people have reported. But once the pwrctrl rework series gets merged,
>> and the rockchip drivers support them, we can bring back the reverted changes.
> 
> FUKAUMI Naoki, just to confirm:

Should I try
  "PCI: dwc: Make Link Up IRQ logic handle already powered on PCIe switches"
  https://lore.kernel.org/r/20251127134318.3655052-2-cassel@kernel.org

instead of below approaches/patches?

> Neither my suggested approach:
> https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
> 
> nor Shawn's suggested approach:
> https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/
> 
> worked for you?
> 
> 
> If so, I don't see many alternative but for Mani to apply patch 1 and
> patch 2 from this series.

Best regards,

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

> Kind regards,
> Niklas
> 

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Niklas Cassel]

On Fri, Nov 28, 2025 at 02:15:28PM +0900, FUKAUMI Naoki wrote:
> Hi Niklas,
> 
> Should I try
>  "PCI: dwc: Make Link Up IRQ logic handle already powered on PCIe switches"
>  https://lore.kernel.org/r/20251127134318.3655052-2-cassel@kernel.org
> 
> instead of below approaches/patches?
> 
> > Neither my suggested approach:
> > https://lore.kernel.org/linux-pci/aRHdeVCY3rRmxe80@ryzen/
> > 
> > nor Shawn's suggested approach:
> > https://lore.kernel.org/linux-pci/dc932773-af5b-4af7-a0d0-8cc72dfbd3c7@rock-chips.com/

Yes please, your Tested-by would be very helpful.

It is basically the same as my patch above, I just sent it as a formal patch.

Since you said that it does indeed work for you, it does seem like a much
better solution. (Because if we would have reverted the patches, we would
have wanted to reapply them some time in the future.)


Kind regards,
Niklas

Re: [PATCH 0/6] PCI: dwc: Revert Link Up IRQ support

[Manivannan Sadhasivam]

On Tue, Nov 11, 2025 at 11:51:00AM +0100, Niklas Cassel wrote:
> Revert all patches related to pcie-designware Root Complex Link Up IRQ
> support.
> 
> While this fake hotplugging was a nice idea, it has shown that this feature
> does not handle PCIe switches correctly:
> pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43
> pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them
> pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44
> pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them
> pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45
> pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them
> pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46
> pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41])
> pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them
> pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46
> pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41])
> pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them
> pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46
> 
> During the initial scan, PCI core doesn't see the switch and since the Root
> Port is not hot plug capable, the secondary bus number gets assigned as the
> subordinate bus number. 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 works perfectly fine for PCIe endpoints connected to the Root Port,
> since they don't extend the bus. However, if a PCIe switch is connected,
> then there is a problem when the downstream busses starts showing up and
> the PCI core doesn't extend the subordinate bus number after initial scan
> during boot.
> 
> The long term plan is to migrate this driver to the pwrctrl framework,
> once it adds proper support for powering up and enumerating PCIe switches.
> 

Could you please rebase this series on top of pci/controller/dwc branch and
repost?

- Mani

> Niklas Cassel (6):
>   Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link
>     Up"
>   Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up
>     IRQ"
>   Revert "PCI: qcom: Don't wait for link if we can detect Link Up"
>   Revert "PCI: qcom: Enable MSI interrupts together with Link up if
>     'Global IRQ' is supported"
>   Revert "PCI: qcom: Enumerate endpoints based on Link up event in
>     'global_irq' interrupt"
>   Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up
>     event"
> 
>  .../pci/controller/dwc/pcie-designware-host.c | 10 +--
>  drivers/pci/controller/dwc/pcie-designware.h  |  1 -
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c | 60 +-----------------
>  drivers/pci/controller/dwc/pcie-qcom.c        | 63 +------------------
>  4 files changed, 6 insertions(+), 128 deletions(-)
> 
> -- 
> 2.51.1
> 

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