Devicetree
 help / color / mirror / Atom feed
* [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
@ 2026-06-28 23:11 Rosen Penev
  2026-06-28 23:27 ` sashiko-bot
  2026-07-27 16:49 ` Florian Fainelli
  0 siblings, 2 replies; 4+ messages in thread
From: Rosen Penev @ 2026-06-28 23:11 UTC (permalink / raw)
  To: devicetree
  Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
	Broadcom internal kernel review list, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley,
	moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list

These addresses overlap with DRAM on BCM5301X/BCM470X SoCs, causing the OF
address translation code to route PCIe MMIO accesses through the AXI bus
space instead of directly to memory, breaking PCIe. Remove the extra
ranges to restore the original single-entry mapping that only covers the
AXI peripheral register space.

Assisted-by: opencode:big-pickle
Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 arch/arm/boot/dts/broadcom/bcm-ns.dtsi | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
index bd52de0faa3e..27a97c8122de 100644
--- a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
@@ -95,10 +95,7 @@ L2: cache-controller@22000 {
 	axi@18000000 {
 		compatible = "brcm,bus-axi";
 		reg = <0x18000000 0x1000>;
-		ranges = <0x00000000 0x18000000 0x00100000>,
-			 <0x08000000 0x08000000 0x08000000>,
-			 <0x20000000 0x20000000 0x08000000>,
-			 <0x28000000 0x28000000 0x08000000>;
+		ranges = <0x00000000 0x18000000 0x00100000>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
  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-27 16:49 ` Florian Fainelli
  1 sibling, 1 reply; 4+ messages in thread
From: sashiko-bot @ 2026-06-28 23:27 UTC (permalink / raw)
  To: Rosen Penev; +Cc: devicetree, conor+dt, robh

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.
--

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.

> diff --git a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
> index 392a257136696..a1062245e5a01 100644
> --- a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
> +++ b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
> @@ -95,10 +95,7 @@ L2: cache-controller@22000 {
>  	axi@18000000 {
>  		compatible = "brcm,bus-axi";
>  		reg = <0x18000000 0x1000>;
> -		ranges = <0x00000000 0x18000000 0x00100000>,
> -			 <0x08000000 0x08000000 0x08000000>,
> -			 <0x20000000 0x20000000 0x08000000>,
> -			 <0x28000000 0x28000000 0x08000000>;
> +		ranges = <0x00000000 0x18000000 0x00100000>;

[Severity: High]
Does removing these PCI memory ranges from the parent axi@18000000 bus break
outbound PCIe memory mapping?

During system boot, when the PCI core calls
devm_of_pci_get_host_bridge_resources() to parse the pcie child node's ranges
property, it translates the PCI memory addresses to CPU physical addresses using
of_translate_address().

Since the pcie nodes are children of the axi@18000000 bus, the translation
must pass through the parent's ranges property. Without the mappings for
0x08000000, 0x20000000, and 0x28000000, the translation fails.

This would cause the PCI core to drop these memory windows, resulting in
pci_assign_unassigned_root_bus_resources() failing to allocate memory BARs,
and endpoint drivers failing at pci_enable_device_mem().

>  		#address-cells = <1>;
>  		#size-cells = <1>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628231156.1254012-1-rosenp@gmail.com?part=1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
  2026-06-28 23:27 ` sashiko-bot
@ 2026-07-03 22:17   ` Rosen Penev
  0 siblings, 0 replies; 4+ messages in thread
From: Rosen Penev @ 2026-07-03 22:17 UTC (permalink / raw)
  To: sashiko-reviews; +Cc: devicetree, conor+dt, robh

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.
> --
>
> 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.
>
> > diff --git a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
> > index 392a257136696..a1062245e5a01 100644
> > --- a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
> > +++ b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
> > @@ -95,10 +95,7 @@ L2: cache-controller@22000 {
> >       axi@18000000 {
> >               compatible = "brcm,bus-axi";
> >               reg = <0x18000000 0x1000>;
> > -             ranges = <0x00000000 0x18000000 0x00100000>,
> > -                      <0x08000000 0x08000000 0x08000000>,
> > -                      <0x20000000 0x20000000 0x08000000>,
> > -                      <0x28000000 0x28000000 0x08000000>;
> > +             ranges = <0x00000000 0x18000000 0x00100000>;
>
> [Severity: High]
> Does removing these PCI memory ranges from the parent axi@18000000 bus break
> outbound PCIe memory mapping?
>
> During system boot, when the PCI core calls
> devm_of_pci_get_host_bridge_resources() to parse the pcie child node's ranges
> property, it translates the PCI memory addresses to CPU physical addresses using
> of_translate_address().
>
> Since the pcie nodes are children of the axi@18000000 bus, the translation
> must pass through the parent's ranges property. Without the mappings for
> 0x08000000, 0x20000000, and 0x28000000, the translation fails.
>
> This would cause the PCI core to drop these memory windows, resulting in
> pci_assign_unassigned_root_bus_resources() failing to allocate memory BARs,
> and endpoint drivers failing at pci_enable_device_mem().
Different AI says:

The review's analysis is wrong because it assumes PCI MMIO windows at
these addresses must translate successfully to be usable. Here's why
the commit actually fixes things:
The problem was that the translation succeeded.
On BCM5301X, 0x08000000, 0x20000000, and 0x28000000 are DRAM
addresses, not PCIe MMIO space. The old AXI bus ranges created 1:1
mappings for these addresses, so of_translate_address() returned them
as-is. The PCI core registered valid-looking resources pointing at
DRAM — MMIO accesses went to memory instead of the PCI bus, corrupting
data.
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.
So the review's objection at https://lore.kernel.org/all/... is
incorrect — the translation was producing wrong resources, and the fix
is to stop producing them.
>
> >               #address-cells = <1>;
> >               #size-cells = <1>;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260628231156.1254012-1-rosenp@gmail.com?part=1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
  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-27 16:49 ` Florian Fainelli
  1 sibling, 0 replies; 4+ messages in thread
From: Florian Fainelli @ 2026-07-27 16:49 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Rosen Penev, devicetree
  Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list

From: Florian Fainelli <f.fainelli@gmail.com>

On Sun, 28 Jun 2026 16:11:56 -0700, Rosen Penev <rosenp@gmail.com> wrote:
> These addresses overlap with DRAM on BCM5301X/BCM470X SoCs, causing the OF
> address translation code to route PCIe MMIO accesses through the AXI bus
> space instead of directly to memory, breaking PCIe. Remove the extra
> ranges to restore the original single-entry mapping that only covers the
> AXI peripheral register space.
> 
> Assisted-by: opencode:big-pickle
> Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/fixes, thanks!
--
Florian

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-07-27 16:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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-27 16:49 ` Florian Fainelli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox