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