From: "Arnd Bergmann" <arnd@arndb.de>
To: "Rosen Penev" <rosenp@gmail.com>, sashiko-reviews@lists.linux.dev
Cc: devicetree@vger.kernel.org, "Conor Dooley" <conor+dt@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Florian Fainelli" <florian.fainelli@broadcom.com>
Subject: Re: [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
Date: Wed, 29 Jul 2026 17:40:32 +0200 [thread overview]
Message-ID: <ba56ee70-9702-4b11-ad04-d63322ab60b4@app.fastmail.com> (raw)
In-Reply-To: <CAKxU2N-3zVUM6A-fQnYWud4O7M55Ghc-wnTCG+8DD6_nh2827g@mail.gmail.com>
I saw this in the fixes pull request, and the descriptions
below don't make much sense to me. I'll hold off on the pull
request until someone can come up with a fix that they
can accurately describe.
On Sat, Jul 4, 2026, at 00:17, Rosen Penev wrote:
> On Sun, Jun 28, 2026 at 4:27 PM <sashiko-bot@kernel.org> wrote:
>>
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [High] Removing the PCI memory ranges from the parent `axi@18000000` bus breaks outbound PCIe memory mapping because the child `pcie` nodes can no longer translate their addresses to CPU physical addresses.
This makes sense to me, but doesn't explain what caused
the observed bug
>> commit 4f061464281d4964ce46dab60d36a09328f14862
>> Author: Rosen Penev <rosenp@gmail.com>
>>
>> ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
>>
>> This commit removes extra AXI bus ranges that overlap with DRAM on
>> BCM5301X/BCM470X SoCs. The intention is to restore the original
>> single-entry mapping and fix PCIe routing issues.
The DRAM ranges on this chip are at 0x00000000 and 0x88000000
and don't overlap with the axi bus ranges at
0x18000000/0x08000000/0x20000000/0x28000000, so the initial
analysis is wrong.
> With need_ob_cfg = false (no brcm,pcie-ob in bcm-ns.dtsi),
> iproc_pcie_map_ranges() is never called. The bootloader has already
> configured the PCIe controller's outbound windows correctly. By
> removing the extra AXI bus ranges, of_translate_address() fails, those
> bogus resources are skipped (the OF_BAD_ADDR check at
> drivers/pci/of.c:377), and the kernel stops registering DRAM addresses
> as PCI MMIO windows. The hardware continues working with its
> pre-configured outbound windows.
This sounds like the bootloader configured ranges don't
match the ones in the devicetree description, which would
leave three options:
- change the bootloader to match the dts
- change the dts to match the bootloader
- change the driver to reconfigure the windows according to DT
Can you check how the OB windows are actually configured
by the bootloader on your board?
Arnd
next prev parent reply other threads:[~2026-07-29 15:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-28 23:11 [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe Rosen Penev
2026-06-28 23:27 ` sashiko-bot
2026-07-03 22:17 ` Rosen Penev
2026-07-29 15:40 ` Arnd Bergmann [this message]
2026-07-29 18:13 ` Rosen Penev
2026-07-29 19:30 ` Arnd Bergmann
2026-07-29 20:26 ` Rosen Penev
2026-07-29 20:43 ` Arnd Bergmann
2026-07-29 20:55 ` Rosen Penev
2026-07-30 8:16 ` Arnd Bergmann
2026-07-27 16:49 ` Florian Fainelli
2026-08-06 10:27 ` Rafał Miłecki
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=ba56ee70-9702-4b11-ad04-d63322ab60b4@app.fastmail.com \
--to=arnd@arndb.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=robh@kernel.org \
--cc=rosenp@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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