Re: [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe

Rosen Penev <[email protected]> Wed, 29 Jul 2026 13:55:35 -0700
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-devicetree
Message-ID <CAKxU2N8LUpmj6ihYrZKN-+8KuQ6zz-XThWWWg9O3KDe3AnfL8g@mail.gmail.com>
On Wed, Jul 29, 2026 at 1:43 PM Arnd Bergmann <[email protected]> wrote:
>
> On Wed, Jul 29, 2026, at 22:26, Rosen Penev wrote:
> > On Wed, Jul 29, 2026 at 12:31 PM Arnd Bergmann <[email protected]> wrote:
> >> On Wed, Jul 29, 2026, at 20:13, Rosen Penev wrote:
> >> > On Wed, Jul 29, 2026 at 8:40 AM Arnd Bergmann <[email protected]> wrote:
> >> >> >> commit 4f061464281d4964ce46dab60d36a09328f14862
> >> >> >> Author: Rosen Penev <[email protected]>
> >> >> >>
> >> >> >> ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
> >> > This patch can be dropped.
> >> >
> >> > https://lore.kernel.org/all/[email protected]/
> >> >
> >> > 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.
Not quite. Full information here: https://github.com/openwrt/openwrt/pull/24415

TL;DR: fails on both platforms for different reasons.

I have no idea how 767012397976 was tested. Maybe without a broadcom wifi card.
>
> 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