From: Bjorn Helgaas <helgaas@kernel.org>
To: Semih Baskan <strst.gs@gmail.com>
Cc: lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
robh@kernel.org, bhelgaas@google.com, rjui@broadcom.com,
sbranden@broadcom.com, bcm-kernel-feedback-list@broadcom.com,
rafal@milecki.pl, florian.fainelli@broadcom.com, arnd@arndb.de,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rosenp@gmail.com,
rani.hod@gmail.com
Subject: Re: [PATCH v2] PCI: iproc: Use the EROM outbound window on BCMA
Date: Fri, 7 Aug 2026 10:27:05 -0500 [thread overview]
Message-ID: <20260807152705.GA59586@bhelgaas> (raw)
In-Reply-To: <20260807035726.387-1-strst.gs@gmail.com>
On Fri, Aug 07, 2026 at 06:57:26AM +0300, Semih Baskan wrote:
> The PCIe outbound window base on Northstar depends on the PCIe Gen2 core
> revision. Revision 0x01 uses 0x08000000, 0x40000000 and 0x48000000 for
> controllers 0 to 2, while revision 0x07 (NS-B0) uses 0x08000000,
> 0x20000000 and 0x28000000. Broadcom's own driver branches on the core
> revision for exactly this reason.
>
> bcm-ns.dtsi is shared by every Northstar SoC, so it cannot carry a value
> that is correct on both. Commit 767012397976 ("ARM: dts: BCM5301X:
> Describe PCIe controllers fully") gave the controllers a ranges property.
> The commit shipped in v7.1.
>
> With that property present, two things go wrong with this driver:
It looks like you're going to present two problems next. They should
be bullets so it's obvious what the first is and what the second is,
e.g.,
- devm_pci_alloc_host_bridge() parses ...
- When the DT window ...
(or whatever the second item is, I'm not sure where it starts)
> devm_pci_alloc_host_bridge() parses those ranges and requests them, then
> this driver adds its own window and requests the whole list a second
> time, so every controller fails to probe with -EBUSY.
>
> When the DT window is used, it is only correct on core revision 0x07. On
> revision 0x01 it points at an address the hardware does not decode, and
> the first MMIO access to a BAR takes an imprecise external abort.
>
> The enumeration ROM reports the correct base for the revision actually
> present, and bcma already provides it as addr_s[0]. Drop any memory
> window that came from the device tree and use that instead, requesting
> only the window this driver owns. This makes the driver correct whether
> or not the DT describes a window.
>
> When a dropped window does not match what the EROM reports, print a
> warning naming both. The mismatch means the devicetree describes a
> window the hardware does not decode, and that should be fixed in the
> dts rather than ignored silently.
>
> The same commit also added compatible = "brcm,iproc-pcie", so these
> nodes now match pcie-iproc-platform. With CONFIG_PCIE_IPROC_PLATFORM
> enabled, which is the default on ARCH_BCM_IPROC, that driver binds them
> first and this driver's probe fails inside devm_pci_alloc_host_bridge().
> This patch fixes the configurations where the BCMA driver is the one in
> use; OpenWrt builds that way, with PCIE_IPROC_PLATFORM disabled. The
> platform path takes the DT window as-is and has the same wrong address
> on core revision 0x01, so that side needs a devicetree fix either way.
>
> Tested on an ASUS RT-N18U (BCM47081) and a Linksys EA9200 (BCM4709),
> both core revision 0x01.
>
> Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
> Tested-by: Rani Hod <rani.hod@gmail.com>
> Cc: stable@vger.kernel.org # v7.1+
> Signed-off-by: Semih Baskan <strst.gs@gmail.com>
> ---
> v1 -> v2: print a warning for every devicetree memory window that does
> not match the EROM window. Requested by Arnd Bergmann:
> https://lore.kernel.org/all/d05ffeca-f289-42dd-b454-5a7c7741c6d5@app.fastmail.com/
>
> v1: https://lore.kernel.org/all/20260727140939.389-1-strst.gs@gmail.com/
> Applies to v7.2-rc5 and unchanged through v7.2-rc6; the file has no
> commits in between.
FWIW, there's no need to rebase for new -rcs. We always apply PCI
patches on -rc1 anyway.
prev parent reply other threads:[~2026-08-07 15:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 3:57 [PATCH v2] PCI: iproc: Use the EROM outbound window on BCMA Semih Baskan
2026-08-07 15:27 ` Bjorn Helgaas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260807152705.GA59586@bhelgaas \
--to=helgaas@kernel.org \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=rafal@milecki.pl \
--cc=rani.hod@gmail.com \
--cc=rjui@broadcom.com \
--cc=robh@kernel.org \
--cc=rosenp@gmail.com \
--cc=sbranden@broadcom.com \
--cc=strst.gs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox