Re: [PATCH v6 01/10] arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Splitting the 16GB 64-bit PCI memory region into four discrete 4GB chunks in reverse order prevents the allocation of any PCI BAR larger than 4GB on rev1 silicon.
- [Medium] Invalid PCI space code used for 64-bit memory regions to work around a bootloader bug.
- [Medium] The commit message erroneously conflates the Device Tree 'n' (non-relocatable) bit with the Linux kernel's internal `IORESOURCE_BUSY` macro.
--

commit ca41553adc6a14507e322cba09be38ac0e0f5fd4
Author: Josua Mayer <josua@solid-run.com>
Subject: arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions

This commit extends the 32-bit PCI memory regions to 3GB and adds 16GB
64-bit memory regions for the LX2160A SoC. It also splits the 64-bit
region into four 4GB chunks for silicon revision 1 to avoid an iATU driver
programming error, and drops the non-relocatable flag.

> IORESOURCE_BUSY is dropped since it has no effect when specified in dts.

Is this description accurate? The IEEE 1275 PCI Device Tree binding defines
bit 31 (0x80000000) in the phys.hi cell as the 'n' bit, which denotes whether
the address is non-relocatable (1) or relocatable (0).

While it shares the same bitwise value as the Linux internal IORESOURCE_BUSY
macro, the DT binding flag does not represent IORESOURCE_BUSY.

> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
> index f54005e37924b..b5f52f3f84c7d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
> @@ -14,8 +14,9 @@ &pcie1 {
[ ... ]
> -	ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
> -		  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
> +	ranges = <0x42000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */

Does this encode an invalid DT representation to work around a bootloader bug?

The value 0x42000000 uses the 32-bit memory space code (bits 25:24 are '10')
instead of the 64-bit space code ('11', which would be 0x43000000). According
to the OpenFirmware PCI binding, 32-bit memory space addresses must fit within
32 bits, and 64-bit regions must use the 64-bit space code.

> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index 479982948ee53..3f63fbf2485e5 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -1193,7 +1193,12 @@ pcie1: pcie@3400000 {
[ ... ]
> -			ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
> +			ranges = <0x42000000 0x87 0x00000000 0x87 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
> +				 <0x42000000 0x86 0x00000000 0x86 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
> +				 <0x42000000 0x85 0x00000000 0x85 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
> +				 <0x42000000 0x84 0x00000000 0x84 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
> +				 <0x02000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */

Does splitting this region into four reverse-ordered chunks prevent the
allocation of PCI BARs larger than 4GB?

By listing the chunks in reverse order (0x87, 0x86, 0x85, 0x84), it prevents
of_pci_range_parser_one() from coalescing them into a single 16GB region. The
PCI subsystem will then register four independent 4GB host bridge windows.

Because the Linux PCI allocator (pci_bus_alloc_resource()) cannot span a single
allocation across multiple root bus windows, any device requesting a BAR larger
than 4GB might fail to allocate resources and become unusable.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com?part=1