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

[Semih Baskan]

On Fri, Sep 18, 2026 at 07:46:42PM +0200, Arnd Bergmann wrote:
> 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.

On the RT-N18U the window is not what the board fails on. The device is
on the first controller, where ranges and the EROM agree (0x08000000 on
both revisions), and the board still does not come up with
pcie-iproc-platform on it. Clearing has_apb_err_disable for
IPROC_PCIE_PAXB, one line, so the driver never touches APB_ERR_EN
(0xf40), makes the same platform-only kernel boot and enumerate the
BCM4360. The flag is set for that type whether or not "brcm,pcie-ob" is
present, and with the property the driver would program OARR in
iproc_pcie_setup() before the enumeration that touches APB_ERR_EN.

The base follows the core revision rather than the firmware. On
revision 0x01 the EROM window of the second and third controller is
0x40000000 and 0x48000000, and Broadcom's driver picks its OMAP/OARR
values by core revision the same way. With "brcm,pcie-ob" the
platform driver would write the ranges value into OARR, which in
bcm-ns.dtsi is the revision 0x07 one for every SoC. Whether a
revision 0x01 core decodes 0x20000000 once OARR says so I have not
tried. In the tree only ns2.dtsi sets the property.

Best regards,
Semih