From: Josua Mayer <josua@solid-run.com>
To: "sashiko@lists.linux.dev" <sashiko@lists.linux.dev>
Cc: "imx@lists.linux.dev" <imx@lists.linux.dev>,
"Frank.Li@kernel.org" <Frank.Li@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v5 01/10] arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions
Date: Tue, 12 May 2026 14:21:24 +0000 [thread overview]
Message-ID: <2ab60e57-6afc-4d71-ab50-a795d6f6d229@solid-run.com> (raw)
In-Reply-To: <20260511212033.23E72C2BCB0@smtp.kernel.org>
Am 11.05.26 um 23:20 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [High] Incorrect PCI Address Space Code for 64-bit prefetchable memory windows.
> - [High] Fragmenting the 16GB region into 4GB chunks breaks allocation of large PCIe BARs.
> - [Medium] Incorrect size for the `pcie4` 64-bit memory region in `fsl-lx2160a-rev2.dtsi`.
> - [Low] Conflation of the Open Firmware `relocatable` bit with the Linux-internal `IORESOURCE_BUSY` macro.
> --
>
> commit bfb49a7c3467d68eca95268c94cbd76b1401fb15
> Author: Josua Mayer <josua@solid-run.com>
>
> arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions
>
> This commit extends the 32-bit PCIe memory regions to 3GB and adds new
> 64-bit memory regions up to 16GB for the LX2160A SoC. It also drops the
> relocatable bit from the existing ranges, and splits the 16GB area into
> 4GB chunks for silicon revision 1 to avoid an ATU programming limitation.
>
> The commit message states:
>
>> - drop IORESOURCE_BUSY flag
>>
>> IORESOURCE_BUSY is dropped since it has no effect when specified in dts.
> Is this description accurate? The bit being dropped (0x80000000, changing
> 0x82000000 to 0x02000000) is the Open Firmware 'n' bit, which designates
> whether the region is relocatable or fixed.
>
> It doesn't appear to be related to the Linux-internal IORESOURCE_BUSY macro.
> Could the commit message be more precise about the flag being modified?
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
> --- 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 {
> 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
> reg-names = "regs", "config";
>
> - 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 the 0x42000000 value correctly specify a 64-bit memory space?
>
> In the device tree PCI bindings, bits 24-25 of the phys.hi cell denote
> the address space. The value 0b10 (0x02000000 or 0x42000000) designates
> a 32-bit memory space, while 0b11 (0x43000000) is required for a 64-bit
> memory space.
>
> If it is flagged as 32-bit, the PCI core's of_pci_range_to_resource()
> will omit the IORESOURCE_MEM_64 flag.
Actually this is being fixed automatically, as can be seen on boot log:
[ 0.978699] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[ 0.978715] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[ 0.978726] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[ 0.978734] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
[ 0.979460] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[ 1.184102] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
[ 1.184219] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0000:00
[ 1.184223] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.184227] pci_bus 0000:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref]
[ 1.184231] pci_bus 0000:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff])
[ 1.184234] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 1.184260] pci 0000:00:00.0: [1957:8d90] type 01 class 0x060400 PCIe Root Port
[ 1.184283] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 1.184291] pci 0000:00:00.0: bridge window [mem 0xa040000000-0xa0470fffff]
[ 1.184350] pci 0000:00:00.0: supports D1 D2
[ 1.184353] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[ 1.185707] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 PCIe Endpoint
[ 1.186168] pci 0000:01:00.0: BAR 0 [mem 0xa040000000-0xa040ffffff 64bit pref]
[ 1.186206] pci 0000:01:00.0: BAR 3 [mem 0xa041000000-0xa041007fff 64bit pref]
[ 1.186231] pci 0000:01:00.0: ROM [mem 0xa041080000-0xa0410fffff pref]
[ 1.187225] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[ 1.187779] pci 0000:01:00.0: VF BAR 0 [mem 0x00000000-0x0000ffff 64bit pref]
[ 1.187782] pci 0000:01:00.0: VF BAR 0 [mem 0x00000000-0x001fffff 64bit pref]: contains BAR 0 for 32 VFs
[ 1.187820] pci 0000:01:00.0: VF BAR 3 [mem 0x00000000-0x00003fff 64bit pref]
[ 1.187823] pci 0000:01:00.0: VF BAR 3 [mem 0x00000000-0x0007ffff 64bit pref]: contains BAR 3 for 32 VFs
[ 1.190514] pci 0000:01:00.1: [8086:1572] type 00 class 0x020000 PCIe Endpoint
...
[ 1.206543] pci_bus 0000:00: max bus depth: 1 pci_try_num: 2
[ 1.206556] pci 0000:00:00.0: bridge window [mem 0xa400000000-0xa404afffff 64bit pref]: assigned
[ 1.206560] pci 0000:00:00.0: bridge window [mem 0xa040000000-0xa0401fffff]: assigned
[ 1.206568] pci 0000:01:00.0: BAR 0 [mem 0xa400000000-0xa400ffffff 64bit pref]: assigned
[ 1.206971] pci 0000:01:00.0: ROM [mem 0xa040000000-0xa04007ffff pref]: assigned
[ 1.206982] pci 0000:01:00.0: VF BAR 0 [mem 0xa404000000-0xa4041fffff 64bit pref]: assigned
[ 1.207161] pci 0000:01:00.0: BAR 3 [mem 0xa404800000-0xa404807fff 64bit pref]: assigned
[ 1.207562] pci 0000:01:00.0: VF BAR 3 [mem 0xa404820000-0xa40489ffff 64bit pref]: assigned
Setting flags 0x43000000 changes bar assignment messages, and adds new errors:
[ 0.967809] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[ 0.967830] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[ 0.967842] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[ 0.967849] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
[ 0.968574] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[ 1.167697] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
[ 1.167826] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0000:00
[ 1.167830] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.167834] pci_bus 0000:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref]
[ 1.167838] pci_bus 0000:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff])
[ 1.167841] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 1.167868] pci 0000:00:00.0: [1957:8d90] type 01 class 0x060400 PCIe Root Port
[ 1.167891] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 1.167955] pci 0000:00:00.0: supports D1 D2
[ 1.167958] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[ 1.169315] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 PCIe Endpoint
[ 1.169733] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit pref]
[ 1.169771] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00007fff 64bit pref]
[ 1.169796] pci 0000:01:00.0: ROM [mem 0x00000000-0x0007ffff pref]
[ 1.170801] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[ 1.171356] pci 0000:01:00.0: VF BAR 0 [mem 0x00000000-0x0000ffff 64bit pref]
[ 1.171359] pci 0000:01:00.0: VF BAR 0 [mem 0x00000000-0x001fffff 64bit pref]: contains BAR 0 for 32 VFs
[ 1.171396] pci 0000:01:00.0: VF BAR 3 [mem 0x00000000-0x00003fff 64bit pref]
[ 1.171399] pci 0000:01:00.0: VF BAR 3 [mem 0x00000000-0x0007ffff 64bit pref]: contains BAR 3 for 32 VFs
[ 1.173389] OF: /soc/pcie@3800000: no msi-map translation for id 0x100 on (null)
[ 1.173515] OF: /soc/pcie@3800000: no iommu-map translation for id 0x100 on (null)
[ 1.173937] pci 0000:01:00.1: [8086:1572] type 00 class 0x020000 PCIe Endpoint
...
[ 1.186848] pci_bus 0000:00: max bus depth: 1 pci_try_num: 2
[ 1.186861] pci 0000:00:00.0: bridge window [mem 0xa400000000-0xa404afffff 64bit pref]: assigned
[ 1.186864] pci 0000:00:00.0: bridge window [mem 0xa040000000-0xa0401fffff]: assigned
[ 1.186871] pci 0000:01:00.0: BAR 0 [mem 0xa400000000-0xa400ffffff 64bit pref]: assigned
[ 1.187197] pci 0000:01:00.0: ROM [mem 0xa040000000-0xa04007ffff pref]: assigned
[ 1.187208] pci 0000:01:00.0: VF BAR 0 [mem 0xa404000000-0xa4041fffff 64bit pref]: assigned
[ 1.187355] pci 0000:01:00.0: BAR 3 [mem 0xa404800000-0xa404807fff 64bit pref]: assigned
[ 1.187680] pci 0000:01:00.0: VF BAR 3 [mem 0xa404820000-0xa40489ffff 64bit pref]: assigned
It appears that bootloader fails initializing the non-VF bars ("mem 0x00000000-0x00ffffff 64bit pref"),
once the 64-bit mem flag is added.
So I shall leave the flags as they are now, without 64-bit.
> Will this cause the PCI allocator
> to fail when assigning 64-bit BARs, as shown in the commit log ("failed
> to assign [mem size 0x200000000 64bit pref]")?
>
> [ ... ]
>
> @@ -63,8 +66,9 @@ &pcie4 {
> 0x98 0x00000000 0x0 0x00002000>; /* configuration space */
> reg-names = "regs", "config";
>
> - ranges = <0x81000000 0x0 0x00000000 0x98 0x00010000 0x0 0x00010000
> - 0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>;
> + ranges = <0x42000000 0x9c 0x00000000 0x9c 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 16GB */
>
> This isn't a bug, but there might be a typo in the size here. The comment
> says 16GB, but the size cells are 0x01 0x00000000 (4GB). The other PCIe
> controllers in this file use 0x04 0x00000000.
This is a bug, it was intended 16GB.
Queued for v6.
>
> [ ... ]
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> --- 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 {
> apio-wins = <8>;
> ppio-wins = <8>;
> bus-range = <0x0 0xff>;
> - 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 */
>
> Does fragmenting the 16GB region into multiple 4GB chunks prevent the
> allocation of larger PCIe BARs?
>
> The Linux PCI allocator requires a single contiguous parent window to
> satisfy a BAR allocation request. By splitting the address space here,
> the root bus will have four separate 4GB parent windows.
>
> Will this make it impossible for the kernel to allocate any contiguous
> BAR larger than 4GB, preventing the successful mapping of the 8GB AI
> accelerator BAR mentioned in the commit message?
>
next prev parent reply other threads:[~2026-05-12 14:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 15:12 [PATCH v5 00/10] arm64: dts: lx2160a: cleanups, add new board, large pci bars Josua Mayer
2026-05-10 15:12 ` [PATCH v5 01/10] arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions Josua Mayer
2026-05-11 21:20 ` sashiko-bot
2026-05-12 14:21 ` Josua Mayer [this message]
2026-05-10 15:12 ` [PATCH v5 02/10] arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi Josua Mayer
2026-05-10 15:12 ` [PATCH v5 03/10] arm64: dts: lx2162a-clearfog: cleanup superfluous status properties Josua Mayer
2026-05-10 15:12 ` [PATCH v5 04/10] arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function Josua Mayer
2026-05-10 15:12 ` [PATCH v5 05/10] dt-bindings: arm: fsl: Add solidrun lx2160a twins board Josua Mayer
2026-05-10 15:12 ` [PATCH v5 06/10] arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag Josua Mayer
2026-05-10 15:12 ` [PATCH v5 07/10] arm64: dts: lx2160a-clearfog-itx: move shared includes to dts Josua Mayer
2026-05-10 15:12 ` [PATCH v5 08/10] arm64: dts: lx2160a: add labels to thermal trip-point nodes Josua Mayer
2026-05-10 15:12 ` [PATCH v5 09/10] arm64: dts: lx2160a-cex7: add labels to i2c buses behind mux Josua Mayer
2026-05-10 15:12 ` [PATCH v5 10/10] arm64: dts: Add support for LX2160 Twins board in single configuration Josua Mayer
2026-05-10 15:23 ` Josua Mayer
2026-05-11 22:29 ` sashiko-bot
2026-05-12 13:39 ` Josua Mayer
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=2ab60e57-6afc-4d71-ab50-a795d6f6d229@solid-run.com \
--to=josua@solid-run.com \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=krzk+dt@kernel.org \
--cc=robh@kernel.org \
--cc=sashiko@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