[PATCH] PCI: iproc: Use pci_alloc_host_bridge() on BCMA

[Semih Baskan]

On Wed, Sep 16, 2026 at 03:01:10PM -0500, Bjorn Helgaas wrote:
> If bcma finds both of these devices via EROM, why do they need a
> "brcm,iproc-pcie" compatible?  If we omitted that compatible, what
> would break?

bcma does not need it. pcie-iproc-platform does.

bcma attaches a child node to a core by comparing the node's reg with
the core's base address, in bcma_of_find_child_device(), and the only
compatible it looks at is the bus's own "brcm,bus-axi". The PCI
devices below then find their nodes by devfn under the core's node,
through pci_set_bus_of_node() and of_pci_find_child_device(). The wifi
nodes in bcm4709-netgear-r8000.dts go back to 5d1f2d2c2530 ("ARM: dts:
BCM5301X: Set 5 GHz wireless frequency limits on Netgear R8000") in
2017, which added pcie0 and pcie1 to the dtsi with reg and nothing
else. The core IRQs have come from the axi node's interrupt-map since
1f80de6863ca ("ARM: BCM5301X: add IRQ numbers for PCIe controller") in
2015.

The only code that matches the compatible is the pcie-iproc-platform
match table. The compatible is also what makes
of_platform_default_populate() create a platform device for the node.
Without one the node would be skipped and the platform driver would
never bind it. That driver reads the ranges, bus-range and the pcie
node's own interrupt-map, through devm_pci_alloc_host_bridge() and
of_irq_parse_and_map_pci(). The BCMA driver does not depend on any of
them. It has taken its window from the EROM since it was added,
552aa843e4c5 made it drop the DT one, and its interrupt comes from
bcma. With the follow-up it reads ranges only to compare them with the
EROM window.

What would break is a build with PCIE_IPROC_PLATFORM and without
PCIE_IPROC_BCMA. No in-tree defconfig sets either symbol. Both default
to y under ARCH_BCM_5301X, so multi_v7_defconfig builds both and would
still get PCIe through bcma. OpenWrt builds only the BCMA one.

The dtbs_check warnings in 767012397976's log would not come back. The
schema behind them, pci-bus.yaml in that log and pci-bus-common.yaml
in current dtschema, is selected by the node name, "^pcie?@", and
requires device_type, ranges and the cell sizes, not a compatible. I
checked with dt-validate from dtschema 2026.6: a pcie at 12000 node with
reg and the cell sizes only gives the same two warnings, and the same
node with device_type and ranges added and still no compatible gives
none.

> Sorry to be dense, I'm probably asking dumb questions because I'm not
> a DT expert.  I just imagine DT as being a substitute for native
> enumeration protocols (e.g., PCI, ACPI, EROM), and as specific to a
> piece of hardware, so this single DT that describes enumerable devices
> with incompatible addresses doesn't fit my simple mental model.

The bcma binding reads the same way. bindings/bus/brcm,bus-axi.txt
says the cores are detected by bcma with the memory ranges they use.
The child nodes are there for what cannot be detected, IRQ numbers in
particular, and for cores that do extra things, such as ChipCommon and
its GPIO chip. Under that binding a pcie node is attached to a core
the EROM found, by reg.

Best regards,
Semih