Since the PCIe controllers gained a full DT description (349/350, commit
24ce1491cc) every controller fails to probe with -EBUSY, and the window
it describes is at the wrong address on most boards.
devm_pci_alloc_host_bridge() parses the DT ranges and requests them, then
pcie-iproc-bcma adds its own window and requests the whole list a second
time, so that second request collides.
The outbound window base is fixed per PCIe core revision. Revision 0x01
uses 0x08000000, 0x40000000 and 0x48000000 for controllers 0 to 2, while
revision 0x07 uses 0x08000000, 0x20000000 and 0x28000000. Broadcom's own
driver branches on the core revision for this reason. 349 carries the
revision 0x07 values, so on revision 0x01 controller 1 points at an
address the hardware does not decode and the first BAR access aborts.
A .dtsi shared by every Northstar SoC cannot express a per-revision
value, but the enumeration ROM reports the right one and bcma already
provides it. Discard any memory window that came from the device tree and
use that instead, requesting only the window this driver owns. The driver
is then correct whether or not the DT describes a window.
Tested on an ASUS RT-N18U (BCM47081) and a Linksys EA9200 (BCM4709), both
core revision 0x01, on kernel 6.18.
Fixes: 24ce1491cc ("bcm53xx: backport pcie patches")
Fixes: https://github.com/openwrt/openwrt/issues/23593
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24415
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
a36ed219f2