Devicetree
 help / color / mirror / Atom feed
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

  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