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

["Arnd Bergmann" <arnd@arndb.de>]

On Fri, Sep 18, 2026, at 18:25, Semih Baskan wrote:
> 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.

Ok, makes sense.

>> 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.

Ok, so adding the regular resource management to both sides here is
probably a good idea anyway, though it is not sufficient as long the
platform driver gets probed first.

>> 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.

Ok

>> 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.

Ah, interesting. So if the problem with the platform driver
is that the outbound windows are mismatched between the register
settings and the ranges property, wouldn't it make sense to always
set "brcm,pcie-ob" for boards that are known to have more than
one possible setting in their firmware?
That way I would hope the platform driver can just work in the cases
that currently fail.

>> 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.

Ok. I suspect this may cause problems when someone uses an MFD
device that needs to translate internal registers of child device
through the ranges. It's probably not a big deal since those devices
are rare, just something to keep in mind.

    Arnd