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

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Sep 16, 2026 at 11:12:28AM +0300, Semih Baskan wrote:
> On Mon, Sep 14, 2026 at 12:46:24PM -0500, Bjorn Helgaas wrote:
> > I guess this goes back to 767012397976 ("ARM: dts: BCM5301X: Describe
> > PCIe controllers fully"), but I'm confused about this.  Why are two
> > incompatible devices (rev 0x01 and 0x07) described with the same DT
> > with address ranges that are wrong for rev 0x01?  I thought DT was
> > supposed to be matched with the hardware in the box?
> 
> Yes, it goes back to that commit. The PCIe nodes are in bcm-ns.dtsi,
> the include behind bcm4708.dtsi, bcm47081.dtsi, bcm4709.dtsi and
> bcm47094.dtsi. Before 767012397976 they had reg and the cell sizes
> only. That commit added the compatible, the interrupt maps, bus-range
> and one set of ranges, and widened the axi node's ranges to the same
> three windows. Its log says it was tested on BCM47094 with the
> platform driver.
> 
> Both revisions are the same PCIe Gen 2 core, BCMA_CORE_NS_PCIEG2, and
> pcie-iproc-bcma matches it at BCMA_ANY_REV. The difference this driver
> meets is the fixed outbound window base. The first controller decodes
> 0x08000000 on both. The second and third decode 0x20000000/0x28000000
> on revision 0x07 (BCM47094) and 0x40000000/0x48000000 on revision 0x01
> (BCM47081 and BCM4709, measured). The values in the DT are the
> revision 0x07 ones. Broadcom's own driver in the 2.6.36 vendor
> kernels, arch/arm/plat-brcm/bcm5301x_pcie.c, has 0x40000000 and
> 0x48000000 as its default table and switches to 0x20000000 and
> 0x28000000 only when the core revision reads 0x7. The enumeration ROM
> reports the same base per core, and that is what the applied patch
> reads through bcma.
> 
> > And I guess I missed this part about the platform and the bcma drivers
> > both trying to claim the same device.  That seems like something that
> > should be solved somewhere in the bus drivers (platform, bcma), not in
> > pcie-iproc-bcma.c and pcie-iproc-platform.c.
> 
> Yes. Both drivers have bound these nodes since 767012397976 in any
> build with both enabled, and neither the applied patch nor the
> follow-up changes which one binds first. The follow-up only stops this
> driver from requesting windows it never programs. It is in the commit
> log because that changes what happens after the collision on revision
> 0x01, and multi_v7_defconfig builds both drivers (both symbols default
> to y under ARCH_BCM_5301X). OpenWrt builds only the BCMA one.
> 
> > Why is this not a problem for other BCMA devices (bgmac_bcma_driver,
> > b43_bcma_driver, brcms_bcma_driver, bcma_hcd_driver)?
> 
> Because the pcie nodes are the only children of the axi node in
> bcm-ns.dtsi with a compatible at all. bcma_bus_register() runs
> of_platform_default_populate() on the axi node before it registers its
> cores, so a core whose node has a compatible gets a device from both
> sides.
> 
> The gmac nodes have no compatible, so only bgmac-bcma binds them;
> bgmac-platform matches brcm,amac, brcm,nsp-amac and brcm,ns2-amac,
> none of which appear there. The usb2 and usb3 nodes have no compatible
> either; bcma-hcd claims the core and populates the generic-ehci, ohci
> and xhci children itself. b43 and brcmsmac have no platform
> counterpart.
> 
> > Is this another consequence of using a DT that describes
> > "brcm,iproc-pcie" controllers that don't match the hardware?  Why
> > don't we have different DTs for these two kinds of hardware?
> 
> The double claim comes from the compatible. Revision 0x07, where the
> DT window matches the EROM, gets the two probes as well, so the ranges
> play no part in it. bcma attaches the node to the core by its reg
> either way, and the wifi child nodes in bcm4709-netgear-r8000.dts hang
> off it, so both drivers see the same node however the ranges are
> split.

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?

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.

Bjorn