From: "Arnd Bergmann" <arnd@arndb.de>
To: "Rosen Penev" <rosenp@gmail.com>
Cc: sashiko-reviews@lists.linux.dev, 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 22:43:26 +0200 [thread overview]
Message-ID: <3e4eb418-d574-4516-8c5a-1488c87baf91@app.fastmail.com> (raw)
In-Reply-To: <CAKxU2N8Akw0+dc=wHUmLrqJe6d6rrk2O-BqeRB7D55iU-S_uLA@mail.gmail.com>
On Wed, Jul 29, 2026, at 22:26, Rosen Penev wrote:
> On Wed, Jul 29, 2026 at 12:31 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Jul 29, 2026, at 20:13, Rosen Penev wrote:
>> > On Wed, Jul 29, 2026 at 8:40 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> >> >> commit 4f061464281d4964ce46dab60d36a09328f14862
>> >> >> Author: Rosen Penev <rosenp@gmail.com>
>> >> >>
>> >> >> ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
>> > This patch can be dropped.
>> >
>> > https://lore.kernel.org/all/20260727140939.389-1-strst.gs@gmail.com/
>> >
>> > is the proper solution to the problem.
>>
>> Right, that looks a lot better, at least as a hotfix. Could you
>> respin that one to print a warning in the loop for every bridge
>> window that is not bdev->addr_s[0]? That way we can also fix
>> up the DT to have the correct data, which at the minimum helps
>> avoid nonsense but may also be needed to avoid future problems.
> Not my patch.
Ah, my mistake
> That patch effectively ignores values in dts. Needed because of bcm drivers.
Sure, but my point is that it fixes a regression introduced by
767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully"),
which tried to address a warning about missing ranges in dts.
As far as I can tell, the patch worked correctly on the
platforms that had the right windows set (presumably bcm47094/ac56u)
but failed when the information was wrong.
Having addressed the build time warning of course is an improvement,
but I would argue that actually having incorrect information is
worse here, even if the information is ignored in the end.
Arnd
next prev parent reply other threads:[~2026-07-29 20:43 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
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 [this message]
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=3e4eb418-d574-4516-8c5a-1488c87baf91@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