[PATCH v4 0/2] PCI: iproc-bcma: Use EROM instead of devicetree

[PATCH v4 0/2] PCI: iproc-bcma: Use EROM instead of devicetree

[Bjorn Helgaas]

This is a combination of these two patches:

  [PATCH v3] PCI: iproc: Use the EROM outbound window on BCMA
  https://lore.kernel.org/all/20260807160526.379-1-strst.gs@gmail.com

  [PATCH] PCI: iproc: Use pci_alloc_host_bridge() on BCMA
  https://lore.kernel.org/all/20260912043626.437-1-strst.gs@gmail.com

I think it's a little simpler because it keeps the use of devm and it
doesn't require two pcie-iproc-bcma.c patches.  I didn't sign off on the
pcie-iproc-bcma.c patch because it's Semih's work except for the minor devm
adaptation.  And the commit log probably needs some work, but I don't know
enough to describe the platform/bcma driver issues.



Bjorn Helgaas (2):
  PCI: Expose devm_pci_alloc_host_bridge_release()
  PCI: iproc: Use the EROM outbound window on BCMA

 drivers/pci/controller/pcie-iproc-bcma.c | 40 ++++++++++++++++++++++--
 drivers/pci/pci.h                        |  1 +
 drivers/pci/probe.c                      |  2 +-
 3 files changed, 39 insertions(+), 4 deletions(-)

-- 
2.53.0

[PATCH v4 1/2] PCI: Expose devm_pci_alloc_host_bridge_release()

[Bjorn Helgaas]

devm_pci_alloc_host_bridge() allocates a struct pci_host_bridge and also
parses device tree resources and claims them.  There are drivers, e.g.,
pcie-iproc-bcma.c, that need to allocate a pci_host_bridge but do not need
device tree resources.

Expose devm_pci_alloc_host_bridge_release() so they can avoid the device
tree parts by calling pci_alloc_host_bridge() directly and adding the devm
release function manually.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 drivers/pci/pci.h   | 1 +
 drivers/pci/probe.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index ba3c3fddddc2..5e21cd29cc7c 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -502,6 +502,7 @@ enum pci_bar_type {
 	pci_bar_mem64,		/* A 64-bit memory BAR */
 };
 
+void devm_pci_alloc_host_bridge_release(void *data);
 struct device *pci_get_host_bridge_device(struct pci_dev *dev);
 void pci_put_host_bridge_device(struct device *dev);
 
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 27008e2ea5af..e214da95ca94 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -696,7 +696,7 @@ struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
 }
 EXPORT_SYMBOL(pci_alloc_host_bridge);
 
-static void devm_pci_alloc_host_bridge_release(void *data)
+void devm_pci_alloc_host_bridge_release(void *data)
 {
 	pci_free_host_bridge(data);
 }
-- 
2.53.0

Re: [PATCH v4 1/2] PCI: Expose devm_pci_alloc_host_bridge_release()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing EXPORT_SYMBOL for devm_pci_alloc_host_bridge_release()
--

commit 3991d0ede1a56c908c8b226f72de68fc49a12993
Author: Bjorn Helgaas <helgaas@kernel.org>

PCI: Expose devm_pci_alloc_host_bridge_release()

This commit exposes devm_pci_alloc_host_bridge_release() so drivers can
avoid device tree parts by calling pci_alloc_host_bridge() directly and
adding the devm release function manually.

> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ea6e77ecfd3f5..b4f781f423a35 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -699,7 +699,7 @@ struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
>  }
>  EXPORT_SYMBOL(pci_alloc_host_bridge);
>  
> -static void devm_pci_alloc_host_bridge_release(void *data)
> +void devm_pci_alloc_host_bridge_release(void *data)

[Severity: Low]
Does this function need an EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
declaration?

Because devm_pci_alloc_host_bridge_release() is defined in the built-in
PCI subsystem but lacks an export, it cannot be linked by external
modules.

Compiling a host controller driver utilizing this devres action
(like drivers/pci/controller/pcie-iproc-bcma.c) as a loadable kernel module
will result in a modpost linker error for an undefined symbol.

>  {
>  	pci_free_host_bridge(data);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013220421.1588051-1-bhelgaas@google.com?part=1

Re: [PATCH v4 1/2] PCI: Expose devm_pci_alloc_host_bridge_release()

[Manivannan Sadhasivam]

On 2026-10-13 17:04 -0500, Bjorn Helgaas wrote:
> devm_pci_alloc_host_bridge() allocates a struct pci_host_bridge and also
> parses device tree resources and claims them.  There are drivers, e.g.,
> pcie-iproc-bcma.c, that need to allocate a pci_host_bridge but do not need
> device tree resources.
> 
> Expose devm_pci_alloc_host_bridge_release() so they can avoid the device
> tree parts by calling pci_alloc_host_bridge() directly and adding the devm
> release function manually.
> 
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

- Mani

[PATCH v4 2/2] PCI: iproc: Use the EROM outbound window on BCMA

[Bjorn Helgaas]

The PCIe outbound window base on Northstar depends on the PCIe Gen2 core
revision. Revision 0x01 uses 0x08000000, 0x40000000 and 0x48000000 for
controllers 0 to 2, while revision 0x07 (NS-B0) uses 0x08000000,
0x20000000 and 0x28000000. Broadcom's own driver branches on the core
revision for exactly this reason.

bcm-ns.dtsi is shared by every Northstar SoC, so it cannot carry a value
that is correct on both. Commit 767012397976 ("ARM: dts: BCM5301X:
Describe PCIe controllers fully") gave the controllers a ranges property.
The commit shipped in v7.1.

With that property present, two things go wrong with this driver:

  1) devm_pci_alloc_host_bridge() parses those ranges and requests them,
     then this driver adds its own window and requests the whole list a
     second time, so every controller fails to probe with -EBUSY.

  2) The DT window itself is only correct on core revision 0x07. On
     revision 0x01 it points at an address the hardware does not decode,
     and the first MMIO access to a BAR takes an imprecise external abort.

The enumeration ROM reports the correct base for the revision actually
present, and bcma already provides it as addr_s[0].

To solve 1), use pci_alloc_host_bridge() directly to avoid the request of
all the DT resources done in pci_parse_request_of_pci_ranges(). Instead,
request the memory window from the EROM.

To solve 2), parse the memory resources from DT and emit a warning if it
describes a window that doesn't match the window from the EROM.  The
mismatch means the devicetree describes a window the hardware does not
decode, and that should be fixed in the dts rather than ignored silently.

The driver is correct whether or not the DT describes a window.

The same commit also added compatible = "brcm,iproc-pcie", so these
nodes now match pcie-iproc-platform. With CONFIG_PCIE_IPROC_PLATFORM
enabled, which is the default on ARCH_BCM_IPROC, that driver binds them
first and this driver's probe fails inside devm_pci_alloc_host_bridge().
This commit fixes the configurations where the BCMA driver is the one in
use; OpenWrt builds that way, with PCIE_IPROC_PLATFORM disabled. The
platform path takes the DT window as-is and has the same wrong address
on core revision 0x01, so that side needs a devicetree fix either way.

Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")

Based on:
  https://patch.msgid.link/20260807160526.379-1-strst.gs@gmail.com
  https://patch.msgid.link/20260912043626.437-1-strst.gs@gmail.com
---
 drivers/pci/controller/pcie-iproc-bcma.c | 40 ++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc-bcma.c b/drivers/pci/controller/pcie-iproc-bcma.c
index 593418c2bc3a..1e258cd8fed4 100644
--- a/drivers/pci/controller/pcie-iproc-bcma.c
+++ b/drivers/pci/controller/pcie-iproc-bcma.c
@@ -11,7 +11,9 @@
 #include <linux/phy/phy.h>
 #include <linux/bcma/bcma.h>
 #include <linux/ioport.h>
+#include <linux/of_address.h>
 
+#include "../pci.h"
 #include "pcie-iproc.h"
 
 
@@ -31,6 +33,29 @@ static int iproc_bcma_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 	return bcma_core_irq(bdev, 5);
 }
 
+static void iproc_bcma_pcie_check_dt_window(struct iproc_pcie *pcie)
+{
+	struct device_node *np = pcie->dev->of_node;
+	struct of_pci_range_parser parser;
+	struct of_pci_range range;
+	struct resource res;
+
+	if (!np || of_pci_range_parser_init(&parser, np))
+		return;
+
+	for_each_of_pci_range(&parser, &range) {
+		if ((range.flags & IORESOURCE_TYPE_BITS) != IORESOURCE_MEM)
+			continue;
+
+		if (of_pci_range_to_resource(&range, np, &res))
+			continue;
+
+		if (res.start != pcie->mem.start || res.end != pcie->mem.end)
+			dev_warn(pcie->dev, "DT window %pR does not match EROM window %pR, using EROM\n",
+				 &res, &pcie->mem);
+	}
+}
+
 static int iproc_bcma_pcie_probe(struct bcma_device *bdev)
 {
 	struct device *dev = &bdev->dev;
@@ -38,10 +63,20 @@ static int iproc_bcma_pcie_probe(struct bcma_device *bdev)
 	struct pci_host_bridge *bridge;
 	int ret;
 
-	bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
+	bridge = pci_alloc_host_bridge(sizeof(*pcie));
 	if (!bridge)
 		return -ENOMEM;
 
+	bridge->dev.parent = dev;
+
+	ret = devm_add_action_or_reset(dev, devm_pci_alloc_host_bridge_release,
+				       bridge);
+	if (ret)
+		return -ENOMEM;
+
+	bridge->swizzle_irq = pci_common_swizzle;
+	bridge->map_irq = iproc_bcma_pcie_map_irq;
+
 	pcie = pci_host_bridge_priv(bridge);
 
 	pcie->dev = dev;
@@ -59,13 +94,12 @@ static int iproc_bcma_pcie_probe(struct bcma_device *bdev)
 	pcie->mem.end = bdev->addr_s[0] + SZ_128M - 1;
 	pcie->mem.name = "PCIe MEM space";
 	pcie->mem.flags = IORESOURCE_MEM;
+	iproc_bcma_pcie_check_dt_window(pcie);
 	pci_add_resource(&bridge->windows, &pcie->mem);
 	ret = devm_request_pci_bus_resources(dev, &bridge->windows);
 	if (ret)
 		return ret;
 
-	bridge->map_irq = iproc_bcma_pcie_map_irq;
-
 	bcma_set_drvdata(bdev, pcie);
 
 	return iproc_pcie_setup(pcie, &bridge->windows);
-- 
2.53.0

Re: [PATCH v4 2/2] PCI: iproc: Use the EROM outbound window on BCMA

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] pci: Module build failure due to unexported devm_pci_alloc_host_bridge_release
--

commit c2644cb699f7409a55741efcebcc09fcf3cf19bd
Author: Bjorn Helgaas <helgaas@kernel.org>

PCI: iproc: Use the EROM outbound window on BCMA

This commit updates the BCMA driver to request the memory window from the
EROM rather than relying on the device tree ranges. It directly uses
pci_alloc_host_bridge() to avoid requesting all DT resources and adds
validation to warn on window mismatches.

Link: https://patch.msgid.link/20260807160526.379-1-strst.gs@gmail.com
Link: https://patch.msgid.link/20260912043626.437-1-strst.gs@gmail.com

> diff --git a/drivers/pci/controller/pcie-iproc-bcma.c b/drivers/pci/controller/pcie-iproc-bcma.c
> index 593418c2bc3aa..1e258cd8fed4f 100644
> --- a/drivers/pci/controller/pcie-iproc-bcma.c
> +++ b/drivers/pci/controller/pcie-iproc-bcma.c
[ ... ]
> @@ -38,10 +63,20 @@ static int iproc_bcma_pcie_probe(struct bcma_device *bdev)
>  	struct pci_host_bridge *bridge;
>  	int ret;
>  
> -	bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> +	bridge = pci_alloc_host_bridge(sizeof(*pcie));
>  	if (!bridge)
>  		return -ENOMEM;
>  
> +	bridge->dev.parent = dev;
> +
> +	ret = devm_add_action_or_reset(dev, devm_pci_alloc_host_bridge_release,
> +				       bridge);

[Severity: Low]
Will this cause a build failure when the driver is configured as a
loadable module?

The symbol devm_pci_alloc_host_bridge_release is defined internally within
drivers/pci/probe.c but doesn't appear to be exported via EXPORT_SYMBOL()
or EXPORT_SYMBOL_GPL(). Does directly referencing it here in
iproc_bcma_pcie_probe() lead to an undefined reference error during
the linker stage?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013220421.1588051-1-bhelgaas@google.com?part=2

Re: [PATCH v4 2/2] PCI: iproc: Use the EROM outbound window on BCMA

[Semih Baskan]

On Tue, Oct 13, 2026 at 05:04:21PM -0500, Bjorn Helgaas wrote:
> The PCIe outbound window base on Northstar depends on the PCIe Gen2 core
> revision. Revision 0x01 uses 0x08000000, 0x40000000 and 0x48000000 for
[...]

Thanks for combining them.

Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Tested-by: Semih Baskan <strst.gs@gmail.com>

Tested on an Asus RT-N18U (BCM47081, PCIe core rev 0x01) with both
patches on OpenWrt's 6.18.55, which carries 767012397976 as a backport,
driver built in. bcma0:7 enumerates the BCM4360 with the same window,
BARs and IRQ as OpenWrt's current image (an earlier version of this
patch), and bcma0:8/9 print the two expected warnings (DT 0x20000000
and 0x28000000 against EROM 0x40000000 and 0x48000000). I did not
build it as a module.

For the commit log, here is a version that describes the bcma and
platform side, in case it helps:

    PCI: iproc: Use the EROM outbound window on BCMA

    The PCIe outbound window base on Northstar depends on the PCIe Gen2
    core revision. Revision 0x01 uses 0x08000000, 0x40000000 and
    0x48000000 for controllers 0 to 2, revision 0x07 (NS-B0) uses
    0x08000000, 0x20000000 and 0x28000000. Broadcom's own driver branches
    on the core revision for this reason. The enumeration ROM reports the
    base for the revision present, and bcma provides it as addr_s[0].

    Commit 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers
    fully"), in v7.1, gave the controllers in bcm-ns.dtsi a ranges
    property with the revision 0x07 values. bcm-ns.dtsi is shared by
    every Northstar SoC. The DT ranges cause two problems for this
    driver:

      1) devm_pci_alloc_host_bridge() parses and requests the DT ranges,
         then the driver adds the EROM window and requests the list a
         second time, so every controller fails to probe with -EBUSY.

      2) The DT window itself is only correct on revision 0x07. On
         revision 0x01, controllers 1 and 2 get an address the hardware
         does not decode, and the first MMIO access to a BAR takes an
         imprecise external abort.

    The window comes from the EROM and the interrupt from bcma. Allocate
    the bridge with pci_alloc_host_bridge() and free it through a devm
    action, so the PCI core no longer parses and requests the DT ranges,
    and request only the EROM window. The driver still reads the DT
    ranges for one check: if the DT describes a memory window that
    differs from the EROM one, it prints a warning, so a wrong dts shows
    up instead of being ignored. The driver works whether or not the DT
    describes a window.

    The same commit also added compatible = "brcm,iproc-pcie", so these
    nodes now match pcie-iproc-platform. With CONFIG_PCIE_IPROC_PLATFORM
    enabled, the default on ARCH_BCM_IPROC, that driver binds them first.
    It takes the DT window as it is, so that path needs a separate fix
    either way. This patch fixes configurations with PCIE_IPROC_PLATFORM
    disabled, such as OpenWrt's.

    Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
    Cc: stable@vger.kernel.org