[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()

[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

[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

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

[Manivannan Sadhasivam]

On 2026-10-13 17:04 -0500, Bjorn Helgaas wrote:
> 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.
> 

Applied this series to controller/iproc-bcma. Note that I changed the authorship
of patch 2/2 to Semih and collected his tags. But I didn't add your s-o-b. Feel
free to do it yourself, if you seem fit.

- Mani

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

[Manivannan Sadhasivam]

On Tue, 13 Oct 2026 17:04:19 -0500, Bjorn Helgaas wrote:
> 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
> 
> [...]

Applied, thanks!

[1/2] PCI: Expose devm_pci_alloc_host_bridge_release()
      commit: 4e93e052afad91ad28e8343d3777c1e5ab8c24d2
[2/2] PCI: iproc: Use the EROM outbound window on BCMA
      commit: 694a9f52a937f272d8aa6e845765e37118c10e17

Best regards,
-- 
மணிவண்ணன் சதாசிவம்

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

[Florian Fainelli]

On 10/13/26 15:04, Bjorn Helgaas wrote:
> 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.

Humm, this is not materially different for me before/after applying tihs 
patch and unfortunately but here is what I am getting with these two 
patches applied on top of Linus' master at 
0fcb05b72344f40806cbe810de8872f1698bf053:

bcma-host-soc 18000000.axi: bus0: Flash type not supported
iproc-pcie 18012000.pcie: host bridge /axi@18000000/pcie@12000 ranges:
iproc-pcie 18012000.pcie:      MEM 0x0008000000..0x000fffffff -> 
0x0008000000
iproc-pcie 18012000.pcie: link: UP
iproc-pcie 18012000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [mem 0x08000000-0x0fffffff]
pci_bus 0000:00: 2-byte config write to 0000:00:00.0 offset 0xc8 may 
corrupt adjacent RW1C bits
pci 0000:00:00.0: [14e4:8011] type 01 class 0x060400 PCIe Root Port
pci 0000:00:00.0: PCI bridge to [bus 00]
pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
8<--- cut here ---
Unhandled fault: external abort on non-linefetch (0x1008) at 0xc896df40
[c896df40] *pgd=0101f811, *pte=18012243, *ppte=18012013
Internal error: : 1008 [#1] SMP ARM
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.3.0-rc7 #324 VOLUNTARY
Hardware name: BCM5301X
PC is at iproc_pcie_config_read32+0x50/0x3c4
LR is at pci_bus_read_config_dword+0x6c/0xb4
pc : [<c044c5b0>]    lr : [<c04264e4>]    psr: 80000093
sp : c881d9f8  ip : c881da38  fp : c1ce1a00
r10: 00000001  r9 : 00000001  r8 : 00000000
r7 : 00000004  r6 : 00000000  r5 : c1ce1a00  r4 : c1ce1f80
r3 : c896df40  r2 : 0000ffff  r1 : 00000f40  r0 : c1ce1a00
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 0000404a  DAC: 00000051
Register r0 information: slab kmalloc-512 start c1ce1a00 pointer offset 
0 size 512
Register r1 information: non-paged memory
Register r2 information: non-paged memory
Register r3 information: 0-page vmalloc region starting at 0xc896d000 
allocated at devm_pci_remap_cfgspace+0x4c/0x88
Register r4 information: slab kmalloc-512 start c1ce1e00 pointer offset 
384 size 512
Register r5 information: slab kmalloc-512 start c1ce1a00 pointer offset 
0 size 512
Register r6 information: NULL pointer
Register r7 information: non-paged memory
Register r8 information: NULL pointer
Register r9 information: non-paged memory
Register r10 information: non-paged memory
Register r11 information: slab kmalloc-512 start c1ce1a00 pointer offset 
0 size 512
Register r12 information: 2-page vmalloc region starting at 0xc881c000 
allocated at kernel_clone+0xb8/0x348
Process swapper/0 (pid: 1, stack limit = 0x0133d9de)
Stack: (0xc881d9f8 to 0xc881e000)
d9e0:                                                       0000072f 
00000007
da00: 00000000 c094fe97 00000801 c044c560 60000013 c1ce1a00 c881da78 
00000000
da20: 00000001 00000001 c1ce1a00 c04264e4 c881da38 c094e684 00000000 
368113e9
da40: c1095d80 c881da78 0000ea60 00000000 c1ce1a00 c0429f08 c1ce1a00 
00000000
da60: 00000000 c1ce1a00 00000000 00000000 00000000 c042a774 00000000 
368113e9
da80: c101ef54 00000008 c1ce1a00 00000000 c1ce1a00 c042a828 40000013 
368113e9
daa0: 00000008 c1ce1a00 00000000 c1ce1c00 00000000 c042bb34 c1260000 
c1ce1c40
dac0: c1ce1a00 00000000 c1ce1c00 40000013 00ff0100 c1260000 00000000 
00000000
dae0: c1ce1c00 00000000 00000001 00000000 c1ce1a00 c042b94c c7ff18c0 
00000000
db00: c7ff1924 00030000 00ff0100 368113e9 014000f8 c1260000 c1ce1c00 
c1ce1c14
db20: 00000001 00000001 00000000 00000000 00000001 c042bcac 00000001 
00000000
db40: 00000001 00000000 00000000 00000000 c881db64 c1ce1e00 00000001 
00000000
db60: c1ce1e00 c1ce2210 c7ff18c0 c1ce1f80 c7ff1924 c042bf58 c1ce1e00 
00000001
db80: 00000000 c042bfdc 00000330 00000001 00000000 c1ce1e00 c1ce2210 
c044bf5c
dba0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
c1ce2210
dbc0: c1c0f140 00000000 c0921b88 c1ce2210 00000001 00000000 00009012 
ffffffed
dbe0: 01060400 c1ce1f80 c1ce1e00 368113e9 00000000 00000000 c1ce2210 
c1ce2200
dc00: c1ce1f80 c1ce1e00 c7ff18c0 00000000 c7ff1924 c044ca40 00000000 
00000000
dc20: 00000000 18012000 18012fff c7ff192c 00000200 00000000 00000000 
00000000
dc40: 00000000 368113e9 c0f740f4 c1ce2210 c0f740f4 c0f740f4 00000000 
00000000
dc60: c0f79d74 c049d398 c1ce2210 00000000 c0f740f4 c049aff4 c0fba560 
c0fba578
dc80: c881dcec c1ce2210 00000000 c049b448 c0fba560 c0f740f4 c881dcec 
c1ce2210
dca0: c10dd240 c049b594 00000000 c881dcec c049b4cc c10dd200 c10dd240 
c04992bc
dcc0: 00000000 c10dd268 c120d7b8 368113e9 c1ce225c c1ce2210 00000001 
c1ce225c
dce0: c10dd200 c049b8b8 c7ff1b88 c1ce2210 00000001 368113e9 c10dd200 
c1ce2210
dd00: c10dd200 c049ba54 c1ce2210 c1ce2210 c10dd200 c049a1a4 c1ce2210 
00000000
dd20: c1ce225c c114aa10 00000000 c04979c0 00000000 00000000 00000000 
00000000
dd40: 00000000 368113e9 00000000 c1ce2200 c114aa10 00000000 00000000 
c7ff1924
dd60: 00000001 c05a4584 c7ff18c0 00000000 00000000 c083fc70 c114aa10 
c05a4774
dd80: 00000000 368113e9 00000000 c881dddc c1028040 00000000 00000000 
00000000
dda0: 00000000 00000000 00000000 00000000 00000000 368113e9 c1095d80 
c7ff18c0
ddc0: c7ff1478 c083fc70 00000000 c114aa10 00000001 00000000 c0a45870 
c05a4a50
dde0: 00000001 368113e9 c05ae584 c1028064 c114aa00 c1028040 c7ff1478 
00000000
de00: c1028070 c05ac398 c1095d80 c1028040 c114aa00 c114aa10 c7ff1478 
00000000
de20: c1c0f4b8 00000000 c0a45870 c05b184c c114aa10 c0f804b0 c0f804b0 
00000000
de40: 00000000 c049d398 c114aa10 00000000 c0f804b0 c049aff4 c0fba560 
c0fba578
de60: c114aa5c c114aa10 00000000 c049b448 c114aa10 c0f804b0 c114aa5c 
c10dd200
de80: c881df0c c049b6a0 00000000 c0f804b0 c049b5c4 c0498ff0 c10dd200 
c10dd254
dea0: c10b0fb4 368113e9 c0828eb0 c1c0f480 00000000 c0f804b0 c10dd200 
c049a438
dec0: c09409c8 00000000 c09409c8 c0f804b0 c1130f80 c0a23978 c1095d80 
c881df0c
dee0: c0a39860 c049c020 00000000 c1130f80 c0a23978 c0a2398c c0f89000 
c0a01314
df00: c1130f9d 00000311 00000000 00000000 00000000 00000000 00000000 
00000000
df20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
df40: 00000000 00000000 00000000 368113e9 0000009d c1130f80 c0a39840 
c0f89000
df60: c0951bd0 c0a39860 00000006 c0a016b0 00000006 00000006 00000000 
c0a004dc
df80: c1095d80 c0f03f80 c07b7924 00000000 00000000 00000000 00000000 
00000000
dfa0: 00000000 c07b7940 00000000 c010012c 00000000 00000000 00000000 
00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 
00000000
Call trace:
  iproc_pcie_config_read32 from pci_bus_read_config_dword+0x6c/0xb4
  pci_bus_read_config_dword from 
pci_bus_generic_read_dev_vendor_id+0x24/0x150
  pci_bus_generic_read_dev_vendor_id from pci_scan_single_device+0x6c/0xc8
  pci_scan_single_device from pci_scan_slot+0x58/0x230
  pci_scan_slot from pci_scan_child_bus_extend+0x28/0x250
  pci_scan_child_bus_extend from pci_scan_bridge_extend+0x290/0x430
  pci_scan_bridge_extend from pci_scan_child_bus_extend+0x1a0/0x250
  pci_scan_child_bus_extend from pci_scan_root_bus_bridge+0x60/0xc8
  pci_scan_root_bus_bridge from pci_host_probe+0x1c/0xb8
  pci_host_probe from iproc_pcie_setup+0x8a0/0xd94
  iproc_pcie_setup from iproc_pltfm_pcie_probe+0x10c/0x1d4
  iproc_pltfm_pcie_probe from platform_probe+0x48/0x84
  platform_probe from really_probe+0xc8/0x2c8
  really_probe from driver_probe_device+0x34/0xb8
  driver_probe_device from __device_attach_driver+0xc8/0xf8
  __device_attach_driver from bus_for_each_drv+0x90/0xe4
  bus_for_each_drv from __device_attach+0xf8/0x164
  __device_attach from device_initial_probe+0x3c/0x48
  device_initial_probe from bus_probe_device+0x28/0x7c
  bus_probe_device from device_add+0x524/0x768
  device_add from of_platform_device_create_pdata+0x90/0xb8
  of_platform_device_create_pdata from of_platform_bus_create+0x1bc/0x360
  of_platform_bus_create from of_platform_populate+0x60/0xb8
  of_platform_populate from bcma_bus_register+0xec/0x5f0
  bcma_bus_register from bcma_host_soc_probe+0x68/0x94
  bcma_host_soc_probe from platform_probe+0x48/0x84
  platform_probe from really_probe+0xc8/0x2c8
  really_probe from driver_probe_device+0x34/0xb8
  driver_probe_device from __driver_attach+0xdc/0x164
  __driver_attach from bus_for_each_dev+0x7c/0xcc
  bus_for_each_dev from bus_add_driver+0xcc/0x1c0
  bus_add_driver from driver_register+0x80/0x11c
  driver_register from bcma_modinit+0x14/0x48
  bcma_modinit from do_one_initcall+0x7c/0x1e0
  do_one_initcall from kernel_init_freeable+0x1e4/0x264
  kernel_init_freeable from kernel_init+0x1c/0x12c
  kernel_init from ret_from_fork+0x14/0x28
Exception stack(0xc881dfb0 to 0xc881dff8)
dfa0:                                     00000000 00000000 00000000 
00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e1510002 0a00000d e594300c e0833001 (e5933000)
---[ end trace 0000000000000000 ]---
note
** replaying previous printk message **
note: swapper/0[1] exited with irqs disabled
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

-- 
Florian

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

[Semih Baskan]

> Humm, this is not materially different for me before/after applying tihs
> patch and unfortunately but here is what I am getting with these two
> patches applied on top of Linus' master at
> 0fcb05b72344f40806cbe810de8872f1698bf053:
[...]
> Unhandled fault: external abort on non-linefetch (0x1008) at 0xc896df40
[...]
> r3 : c896df40  r2 : 0000ffff  r1 : 00000f40  r0 : c1ce1a00
[...]
>   pci_host_probe from iproc_pcie_setup+0x8a0/0xd94
>   iproc_pcie_setup from iproc_pltfm_pcie_probe+0x10c/0x1d4

The series only changes the pcie-iproc-bcma path, and this kernel probes
the controller with pcie-iproc-platform, so the patches do not run here.

I think the abort is the read of APB_ERR_EN at offset 0xf40 (r1). I
measured the same on an RT-N18U (core revision 0x01) in September: the
platform-only kernel does not come up, and with this one line it boots
and enumerates the BCM4360 [1]:

--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1388,7 +1388,7 @@
         break;
     case IPROC_PCIE_PAXB:
         regs = iproc_pcie_reg_paxb;
-        pcie->has_apb_err_disable = true;
+        pcie->has_apb_err_disable = false;
         if (pcie->need_ob_cfg) {
             pcie->ob_map = paxb_ob_map;
             pcie->ob.nr_windows = ARRAY_SIZE(paxb_ob_map);

[1] https://lore.kernel.org/all/CAAsRjRnV-RTddO6h2XCUz2N5pB0pS8i_-_2XRcD=WOTA7AAFZQ@mail.gmail.com/

Best regards,
Semih

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

[Florian Fainelli]

On 10/15/26 11:51, Semih Baskan wrote:
>> Humm, this is not materially different for me before/after applying tihs
>> patch and unfortunately but here is what I am getting with these two
>> patches applied on top of Linus' master at
>> 0fcb05b72344f40806cbe810de8872f1698bf053:
> [...]
>> Unhandled fault: external abort on non-linefetch (0x1008) at 0xc896df40
> [...]
>> r3 : c896df40  r2 : 0000ffff  r1 : 00000f40  r0 : c1ce1a00
> [...]
>>    pci_host_probe from iproc_pcie_setup+0x8a0/0xd94
>>    iproc_pcie_setup from iproc_pltfm_pcie_probe+0x10c/0x1d4
> 
> The series only changes the pcie-iproc-bcma path, and this kernel probes
> the controller with pcie-iproc-platform, so the patches do not run here.

Yes, clearly not enough coffee, thank you Semih.

> 
> I think the abort is the read of APB_ERR_EN at offset 0xf40 (r1). I
> measured the same on an RT-N18U (core revision 0x01) in September: the
> platform-only kernel does not come up, and with this one line it boots
> and enumerates the BCM4360 [1]:
> 
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -1388,7 +1388,7 @@
>           break;
>       case IPROC_PCIE_PAXB:
>           regs = iproc_pcie_reg_paxb;
> -        pcie->has_apb_err_disable = true;
> +        pcie->has_apb_err_disable = false;
>           if (pcie->need_ob_cfg) {
>               pcie->ob_map = paxb_ob_map;
>               pcie->ob.nr_windows = ARRAY_SIZE(paxb_ob_map);

Yes that works for me, and I was able to establish the last working 
baseline was v7.0 which did not include 
76701239797698b620f2b7ec713fe08ef50ee664 ("ARM: dts: BCM5301X: Describe 
PCIe controllers fully"), whereas v7.1 and onwards crashes unless your 
patch is applied.

Also, the good thing is that my local test bed has been resurrected and 
will be more regularly testing now.

> 
> [1] https://lore.kernel.org/all/CAAsRjRnV-RTddO6h2XCUz2N5pB0pS8i_-_2XRcD=WOTA7AAFZQ@mail.gmail.com/
> 
> Best regards,
> Semih


-- 
Florian

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

[Bjorn Helgaas]

On Thu, Oct 15, 2026 at 12:10:22PM -0700, Florian Fainelli wrote:
> On 10/15/26 11:51, Semih Baskan wrote:
> > > Humm, this is not materially different for me before/after applying tihs
> > > patch and unfortunately but here is what I am getting with these two
> > > patches applied on top of Linus' master at
> > > 0fcb05b72344f40806cbe810de8872f1698bf053:
> > [...]
> > > Unhandled fault: external abort on non-linefetch (0x1008) at 0xc896df40
> > [...]
> > > r3 : c896df40  r2 : 0000ffff  r1 : 00000f40  r0 : c1ce1a00
> > [...]
> > >    pci_host_probe from iproc_pcie_setup+0x8a0/0xd94
> > >    iproc_pcie_setup from iproc_pltfm_pcie_probe+0x10c/0x1d4
> > 
> > The series only changes the pcie-iproc-bcma path, and this kernel probes
> > the controller with pcie-iproc-platform, so the patches do not run here.
> 
> Yes, clearly not enough coffee, thank you Semih.
> 
> > I think the abort is the read of APB_ERR_EN at offset 0xf40 (r1). I
> > measured the same on an RT-N18U (core revision 0x01) in September: the
> > platform-only kernel does not come up, and with this one line it boots
> > and enumerates the BCM4360 [1]:
> > 
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -1388,7 +1388,7 @@
> >           break;
> >       case IPROC_PCIE_PAXB:
> >           regs = iproc_pcie_reg_paxb;
> > -        pcie->has_apb_err_disable = true;
> > +        pcie->has_apb_err_disable = false;
> >           if (pcie->need_ob_cfg) {
> >               pcie->ob_map = paxb_ob_map;
> >               pcie->ob.nr_windows = ARRAY_SIZE(paxb_ob_map);
> 
> Yes that works for me, and I was able to establish the last working baseline
> was v7.0 which did not include 76701239797698b620f2b7ec713fe08ef50ee664
> ("ARM: dts: BCM5301X: Describe PCIe controllers fully"), whereas v7.1 and
> onwards crashes unless your patch is applied.

I assume this means
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=controller/iproc-bcma&id=9850907ee1dd4376c09c4129e0adbe3b39d191b7
is ok after all?

I do think it's unexpected that the kernel would panic even if the
correct driver hasn't been loaded.

If we don't have the right driver for the PCI controller, ideally the
wrong driver's .probe() method wouldn't be called at all, and if it
*is* called, its .probe() should fail gracefully.

The kernel shouldn't panic until it fails to find a root filesystem.

> Also, the good thing is that my local test bed has been resurrected and will
> be more regularly testing now.
> 
> > 
> > [1] https://lore.kernel.org/all/CAAsRjRnV-RTddO6h2XCUz2N5pB0pS8i_-_2XRcD=WOTA7AAFZQ@mail.gmail.com/
> > 
> > Best regards,
> > Semih
> 
> 
> -- 
> Florian