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

On Fri, Sep 18, 2026, at 10:29, Semih Baskan wrote:
> On Thu, Sep 17, 2026 at 10:27:54PM +0200, Arnd Bergmann wrote:
>> Would it be help to change the probe order so the bcma driver
>> always comes before the platform driver?
>
> Only where the DT window matches the EROM one, because that is where
> the platform driver backs out.

I'm probably missing one of the steps here, sorry I'm not too
familiar with the platform.

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?

> With of_platform_default_populate() moved after
> bcma_register_devices() as a test, it boots. pcie-iproc-bcma takes the
> first controller and enumerates the BCM4360 as before. The platform
> driver then probes the same node and fails in
> devm_pci_alloc_host_bridge(), which it reports as -ENOMEM:
>
>   iproc-pcie 18012000.pcie: resource collision: [mem
> 0x08000000-0x0fffffff] conflicts with PCIe MEM space [mem
> 0x08000000-0x0fffffff]

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?
That way, the platform driver would just not be able to
probe on a bcma based SoC regardless of the memory window
settings.

> On the second and third controllers the DT window is
> 0x20000000/0x28000000 and the EROM one 0x40000000/0x48000000, so the
> platform driver's request goes through and its probe carries on with
> the DT window until the link check, which fails because nothing is
> connected to those two on this board. That is as far as this board can
> show.

A few more questions, for my understanding:

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?

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?

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

      Arnd