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

[Semih Baskan]

On Fri, Sep 18, 2026 at 12:32:12PM +0200, Arnd Bergmann wrote:
> If the DT window doesn't match, how does the bcma driver find
> the device node that corresponds to the EROM entry to populate
> the child nodes?

By reg. bcma_of_find_child_device() in drivers/bcma/main.c compares the
first reg address of each child of the axi node with the core's register
base from the EROM. That base is 0x18012000, 0x18013000 and 0x18014000
on both revisions; only the outbound window differs. The pcie node's
ranges is not looked at. The reg is translated through the axi node's
first ranges entry. The PCI core then matches the wifi nodes below that
node by devfn.

> The driver should probably check earlier if the device is
> already bound to the bcma bus, rather than just trying to
> request the bus windows. If anything, I would have expected
> the conflict on the 18012000 address for the register
> base.
>
> I see an ioremap() of bdev->addr in drivers/bcma/scan.c but
> don't see a corresponding request_resource() for it, so maybe
> an easy fix is to add this to the bcma bus scan and
> make sure that always happens before the pci driver probe?

In the tree as it is, neither side claims the register base. bcma
only ioremaps it in scan.c, and pcie-iproc-platform maps its reg with
devm_pci_remap_cfgspace(), which does not request the region either.
That is why the window is the first thing the two collide on. On the
ordering, bcma_bus_register() calls bcma_bus_scan(), then
of_platform_default_populate(), then bcma_register_devices(), so the
scan is done before the pcie platform devices are created and the
bcma core devices are registered after that.

> If a board has nothing connected to one of the host bridges,
> why is the pcie host bridge still marked as status="ok"?
> Do you need a driver to put it into low-power mode, or
> should this just be marked as disabled?

The three nodes are in bcm-ns.dtsi without a status property, and no
Northstar board file disables one. Which controllers carry a device
differs per board: the RT-N18U has one on the first, the R8000 on the
first, and on the second through a switch with two radios behind it.
bcma takes the cores from the EROM, and bcma_register_devices() skips a
core whose node is not available, so a node marked status = "disabled"
is skipped there too, and neither driver would take that core. I do not
know whether an unused core needs a driver for power.

> Does the platform driver reprogram the windows to match the DT
> description, or does it rely on the boot loader to ensure they
> ranges/dma-ranges properties match the register contents?

It programs OARR/OMAP from ranges only when the node has
"brcm,pcie-ob", and the inbound side only when it has dma-ranges.
The bcm-ns.dtsi nodes have neither, so it programs nothing and runs
with what is in the registers at boot. The PAXB_BCMA register table
has no OARR/OMAP at all, and the bcma driver never asks for an
outbound mapping, so it does not program them either. OARR0/OMAP0
are in the PAXB table the platform driver uses, at 0xd20 and 0xd40;
I have not written them on revision 0x01. Broadcom's 2.6.36 driver
writes OMAP/OARR 1:1 from its own table: 0x08000000, 0x40000000 and
0x48000000, with the last two replaced by 0x20000000 and 0x28000000
when the core revision reads 0x07.

> When using the bcma driver, does that update the ranges properties
> in memory to match the EROM contents?

No. 552aa843e4c5 drops the windows parsed from ranges out of the
bridge's resource list and adds the EROM one; the patch in this
thread reads ranges only to compare them with the EROM window. The
property in the live tree is not touched, so /proc/device-tree keeps
the dtsi values and the mismatch shows up only as the warning.

Best regards,
Semih