[PATCH v7 0/9] arm64: dts: lx2160a: cleanups, add new board, large pci bars

[PATCH v7 0/9] arm64: dts: lx2160a: cleanups, add new board, large pci bars

[Josua Mayer]

This patch-set is made of 3 parts:

1. Extend lx2160 pci node ranges to support 16-bit, and large 64-bit
   bars. LX2160A SoC has always supported this, and SolidRun carried it
   in vendor fork for several years now.

2. Cleanup some status properties in LX2162A Clearfog dts.

3. Add description for solidrun twins baord with single LX2160A CEX-7
   module.

There are no inter-dependencies between the parts and they may apply
individually if necessary.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v7:
- Dropped pcie silicon 1 changes because they add too much noise.
- Changed pcie range flags per sashiko feedback.
  This also fixed bootloader patching issues seen previously.
- Added CEX-7 module onboard USB Hub.
- Keep first usb controller disabled in cex-7 module.
- Added reasoning for adding nly single configuration binding to commit
  description.
  (Reported-by: Krzysztof Kozlowski <krzk@kernel.org>)
- Squashed DT label commits with their user (twins board dts).
  (Reported-by: Krzysztof Kozlowski <krzk@kernel.org>)
- Link to v6: https://lore.kernel.org/r/20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com

Changes in v6:
- Add explanation why IORESOURCE_MEM_64 flag is not set.
- Fixed pci bar size 1GB/4GB typo in pcie4 node.
- Enable twins board pcie controller node.
- Fixed function-enumerator value for led-sfp-3.
- Reverted accidental change of clearfog-cx soc revision.
- Link to v5: https://lore.kernel.org/r/20260510-lx2160-pci-v5-0-540b83852227@solid-run.com

Changes in v5:
- add new board
- add cleanups to existing solidrun boards
- pci: extend to lx2160a-rev2 dtsi
- pci: remove non-standard flags to pass dtbs_check
- Link to v4: https://lore.kernel.org/r/20260302-lx2160-pci-v4-1-30a30dc47ec6@solid-run.com

Changes in v4
- dropped accidentally added empty line at top of file:
- actually drop RFC prefix
- rebased on v7.0-rc1 and re-tested on v7.0-rc2
- Link to v3: https://lore.kernel.org/r/20250907-lx2160-pci-v3-1-bb66cc41b8f9@solid-run.com

Changes in v3:
- dropped rfc label
- adjusted flags
- split 16GB area into 4x4GB sections.
- enhance commit description with details explanation
- Link to v2: https://lore.kernel.org/r/20240429-lx2160-pci-v2-1-1b94576d6263@solid-run.com

Changes in v2:
- adjusted flags to fix several errors during probe and bar allocation
- explicitly tested with 2 pci cards on Debian (Linux 6.1)
- still rfc because a limitation in designware pci driver
- Link to v1: https://lore.kernel.org/r/20240321-lx2160-pci-v1-1-3673708f7eb6@solid-run.com

---
Josua Mayer (9):
      arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
      arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi
      arm64: dts: lx2162a-clearfog: cleanup superfluous status properties
      arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function
      dt-bindings: arm: fsl: Add solidrun lx2160a twins board
      arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag
      arm64: dts: lx2160a-clearfog-itx: move shared includes to dts
      arm64: dts: lx2160a-cex7: add usb hub
      arm64: dts: Add support for LX2160 Twins board in single configuration

 Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
 arch/arm64/boot/dts/freescale/Makefile             |   2 +
 .../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi |  41 +-
 .../boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts |   2 +
 .../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi    |   7 +-
 .../boot/dts/freescale/fsl-lx2160a-half-twins.dts  | 830 +++++++++++++++++++++
 .../boot/dts/freescale/fsl-lx2160a-honeycomb.dts   |   2 +
 .../arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi |  30 +-
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi     |  24 +-
 .../boot/dts/freescale/fsl-lx2162a-clearfog.dts    |  37 +-
 10 files changed, 915 insertions(+), 61 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20240118-lx2160-pci-4bdb196e58f3

Best regards,
-- 
Josua Mayer <josua@solid-run.com>

[PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Josua Mayer]

LX2160 SoC pci-e controller supports 64-bit memory regions up to 16GB,
32-bit regions up to 3GB and 16-bit regions up to 64k.

For each pci-e controller:
- extend the existing 32-bit regions to 3GB size
- add 64-bit region
See [1] and [2] for boot messages showing ranges before and after.

On LX2160A Silicon revision 1, the pcie driver fails to program atu for
ranges larger than 4GB [3]. Therefore changes are limited to revision 2.

Similar memory allocation with similar flags was tested with UEFI and ACPI
on pcie3 and pcie5, on a variety of nxp vendor fork versions.

This patch was tested on Linux v7.1-rc1 and u-boot, with two pcie cards:
- pcie5: Radeon Pro WX2100
- pcie3: ADATA NVME

This fixes allocation of large, and 64-bit BARs as requested by many pci
cards - especially graphics processors or AI accelerators, e.g.:

[    2.941187] pci 0000:01:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]
[    2.948834] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]

[1] example of new allocations (pcie5):
[    1.182745] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[    1.182760] layerscape-pcie 3800000.pcie:      MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[    1.182771] layerscape-pcie 3800000.pcie:      MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[    1.182778] layerscape-pcie 3800000.pcie:       IO 0xa000010000..0xa00001ffff -> 0x0000000000
[    1.183642] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[    1.385429] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
[    1.385481] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
[    1.385484] pci_bus 0001:00: root bus resource [bus 00-ff]
[    1.385488] pci_bus 0001:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref]
[    1.385491] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff])
[    1.385494] pci_bus 0001:00: root bus resource [io  0x10000-0x1ffff] (bus address [0x0000-0xffff])
[    1.385516] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
[    1.385538] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
[    1.385544] pci 0001:00:00.0:   bridge window [io  0x11000-0x11fff]
[    1.385548] pci 0001:00:00.0:   bridge window [mem 0xa040000000-0xa0502fffff]
[    1.385605] pci 0001:00:00.0: supports D1 D2
[    1.385607] pci 0001:00:00.0: PME# supported from D0 D1 D2 D3hot
[    1.386778] pci 0001:01:00.0: [1002:6995] type 00 class 0x030000 PCIe Legacy Endpoint
[    1.387336] pci 0001:01:00.0: BAR 0 [mem 0xa040000000-0xa04fffffff 64bit pref]
[    1.387368] pci 0001:01:00.0: BAR 2 [mem 0xa050000000-0xa0501fffff 64bit pref]
[    1.387385] pci 0001:01:00.0: BAR 4 [io  0x11000-0x110ff]
[    1.387402] pci 0001:01:00.0: BAR 5 [mem 0xa050200000-0xa05023ffff]
[    1.387418] pci 0001:01:00.0: ROM [mem 0xa050240000-0xa05025ffff pref]
[    1.387493] pci 0001:01:00.0: enabling Extended Tags
[    1.388960] pci 0001:01:00.0: supports D1 D2

[2] example of previous allocations (pcie5):
[    1.716744] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[    1.724060] layerscape-pcie 3800000.pcie:      MEM 0xa040000000..0xa07fffffff -> 0x0040000000
[    1.733277] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[    1.836220] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
[    1.842186] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
[    1.848883] pci_bus 0001:00: root bus resource [bus 00-ff]
[    1.854363] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa07fffffff] (bus address [0x40000000-0x7fffffff])
[    1.864892] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
[    1.872216] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
[    1.877438] pci 0001:00:00.0:   bridge window [io  0x1000-0x1fff]
[    1.883526] pci 0001:00:00.0:   bridge window [mem 0xa040000000-0xa0502fffff]

[3] error programming atu beyond 4GB:
[    1.716762] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[    1.724080] layerscape-pcie 3800000.pcie:      MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[    1.732615] layerscape-pcie 3800000.pcie:      MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[    1.741142] layerscape-pcie 3800000.pcie:       IO 0xa010000000..0xa01000ffff -> 0x0000000000
[    1.750379] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[    1.759089] layerscape-pcie 3800000.pcie: Failed to set MEM range [mem 0xa400000000-0xa7ffffffff flags 0x2200]
[    1.769089] layerscape-pcie 3800000.pcie: probe with driver layerscape-pcie failed with error -22

[4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
[    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
[    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.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)

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 .../arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 30 +++++++++++++---------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
index f54005e37924b..db1ebee53f6f0 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 {
 	      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 = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
+		 <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+		 <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
 
 	interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "intr";
@@ -30,8 +31,9 @@ &pcie2 {
 	       0x88 0x00000000 0x0 0x00002000>; /* configuration space */
 	reg-names = "regs", "config";
 
-	ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000
-		  0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>;
+	ranges = <0x81000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
+		 <0x82000000 0x00 0x40000000 0x88 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+		 <0xC3000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
 
 	interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "intr";
@@ -46,8 +48,9 @@ &pcie3 {
 	       0x90 0x00000000 0x0 0x00002000>; /* configuration space */
 	reg-names = "regs", "config";
 
-	ranges = <0x81000000 0x0 0x00000000 0x90 0x00010000 0x0 0x00010000
-		  0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>;
+	ranges = <0x81000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
+		 <0x82000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+		 <0xC3000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
 
 	interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "intr";
@@ -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 = <0x81000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
+		 <0x82000000 0x00 0x40000000 0x98 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+		 <0xC3000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
 
 	interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "intr";
@@ -79,8 +83,9 @@ &pcie5 {
 	       0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
 	reg-names = "regs", "config";
 
-	ranges = <0x81000000 0x0 0x00000000 0xa0 0x00010000 0x0 0x00010000
-		  0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>;
+	ranges = <0x81000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
+		 <0x82000000 0x00 0x40000000 0xa0 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+		 <0xC3000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
 
 	interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "intr";
@@ -95,8 +100,9 @@ &pcie6 {
 	       0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
 	reg-names = "regs", "config";
 
-	ranges = <0x81000000 0x0 0x00000000 0xa8 0x00010000 0x0 0x00010000
-		  0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>;
+	ranges = <0x81000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
+		 <0x82000000 0x00 0x40000000 0xa8 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+		 <0xC3000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
 
 	interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "intr";

-- 
2.51.0

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Josua Mayer]

Am 24.05.26 um 16:54 schrieb Josua Mayer:
> LX2160 SoC pci-e controller supports 64-bit memory regions up to 16GB,
> 32-bit regions up to 3GB and 16-bit regions up to 64k.
>
> For each pci-e controller:
> - extend the existing 32-bit regions to 3GB size
> - add 64-bit region
> See [1] and [2] for boot messages showing ranges before and after.
>
> On LX2160A Silicon revision 1, the pcie driver fails to program atu for
> ranges larger than 4GB [3]. Therefore changes are limited to revision 2.
>
> Similar memory allocation with similar flags was tested with UEFI and ACPI
> on pcie3 and pcie5, on a variety of nxp vendor fork versions.
>
> This patch was tested on Linux v7.1-rc1 and u-boot, with two pcie cards:
> - pcie5: Radeon Pro WX2100
> - pcie3: ADATA NVME
>
> This fixes allocation of large, and 64-bit BARs as requested by many pci
> cards - especially graphics processors or AI accelerators, e.g.:
>
> [    2.941187] pci 0000:01:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]
> [    2.948834] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]
>
> [1] example of new allocations (pcie5):
> [    1.182745] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [    1.182760] layerscape-pcie 3800000.pcie:      MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
> [    1.182771] layerscape-pcie 3800000.pcie:      MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
> [    1.182778] layerscape-pcie 3800000.pcie:       IO 0xa000010000..0xa00001ffff -> 0x0000000000
> [    1.183642] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
> [    1.385429] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
> [    1.385481] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
> [    1.385484] pci_bus 0001:00: root bus resource [bus 00-ff]
> [    1.385488] pci_bus 0001:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref]
> [    1.385491] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff])
> [    1.385494] pci_bus 0001:00: root bus resource [io  0x10000-0x1ffff] (bus address [0x0000-0xffff])
> [    1.385516] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
> [    1.385538] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
> [    1.385544] pci 0001:00:00.0:   bridge window [io  0x11000-0x11fff]
> [    1.385548] pci 0001:00:00.0:   bridge window [mem 0xa040000000-0xa0502fffff]
> [    1.385605] pci 0001:00:00.0: supports D1 D2
> [    1.385607] pci 0001:00:00.0: PME# supported from D0 D1 D2 D3hot
> [    1.386778] pci 0001:01:00.0: [1002:6995] type 00 class 0x030000 PCIe Legacy Endpoint
> [    1.387336] pci 0001:01:00.0: BAR 0 [mem 0xa040000000-0xa04fffffff 64bit pref]
> [    1.387368] pci 0001:01:00.0: BAR 2 [mem 0xa050000000-0xa0501fffff 64bit pref]
> [    1.387385] pci 0001:01:00.0: BAR 4 [io  0x11000-0x110ff]
> [    1.387402] pci 0001:01:00.0: BAR 5 [mem 0xa050200000-0xa05023ffff]
> [    1.387418] pci 0001:01:00.0: ROM [mem 0xa050240000-0xa05025ffff pref]
> [    1.387493] pci 0001:01:00.0: enabling Extended Tags
> [    1.388960] pci 0001:01:00.0: supports D1 D2
>
> [2] example of previous allocations (pcie5):
> [    1.716744] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [    1.724060] layerscape-pcie 3800000.pcie:      MEM 0xa040000000..0xa07fffffff -> 0x0040000000
> [    1.733277] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
> [    1.836220] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
> [    1.842186] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
> [    1.848883] pci_bus 0001:00: root bus resource [bus 00-ff]
> [    1.854363] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa07fffffff] (bus address [0x40000000-0x7fffffff])
> [    1.864892] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
> [    1.872216] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
> [    1.877438] pci 0001:00:00.0:   bridge window [io  0x1000-0x1fff]
> [    1.883526] pci 0001:00:00.0:   bridge window [mem 0xa040000000-0xa0502fffff]
>
> [3] error programming atu beyond 4GB:
> [    1.716762] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
> [    1.724080] layerscape-pcie 3800000.pcie:      MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
> [    1.732615] layerscape-pcie 3800000.pcie:      MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
> [    1.741142] layerscape-pcie 3800000.pcie:       IO 0xa010000000..0xa01000ffff -> 0x0000000000
> [    1.750379] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
> [    1.759089] layerscape-pcie 3800000.pcie: Failed to set MEM range [mem 0xa400000000-0xa7ffffffff flags 0x2200]
> [    1.769089] layerscape-pcie 3800000.pcie: probe with driver layerscape-pcie failed with error -22
>
> [4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
> [    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
> [    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.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)
I meant to drop this bootloader error log, because after fixing the ranges flags
this is no longer an issue with this v7 patch.

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Expanding the 32-bit PCI outbound window to 3GB causes it to overlap with the inbound system memory address space, breaking DMA.
- [High] The introduction of the 64-bit PCI memory range causes existing U-Boot bootloaders to fail device tree patching, breaking MSI and IOMMU.
--

commit a80e2e3f97808fdad781240469c5e07e019191e9
Author: Josua Mayer <josua@solid-run.com>

arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

This commit extends the 32-bit PCIe memory regions to 3GB and adds 64-bit
PCIe memory regions for LX2160A rev2. This allows allocation of large BARs
requested by graphics processors or AI accelerators.

> [4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
> [    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
> [    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.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)

[Severity: High]
Does adding the 64-bit PCI memory range cause existing U-Boot bootloaders to
fail device tree patching?

When U-Boot encounters the 64-bit range, it appears fdt_fixup_pcie() aborts
and fails to append the msi-map and iommu-map properties.

Without iommu-map, the kernel will not attach the SMMU to the PCIe devices.
Without msi-map, the kernel cannot translate PCIe Requester IDs to ITS
Device IDs, which breaks MSI/MSI-X allocations.

Could this prevent devices like NVMe drives from initializing and break
compatibility with existing deployed bootloaders?

> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
> index f54005e37924b..db1ebee53f6f0 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 {
>  	      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 = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
> +		 <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
> +		 <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */

[Severity: High]
Does expanding the 32-bit PCI outbound window to 3GB (0xc0000000) cause it to
overlap with inbound system memory?

System memory starts at physical address 0x80000000. Since there isn't a
dma-ranges property mapping inbound DMA to a different bus address, system
memory uses a 1:1 mapping, meaning inbound DMA targets 0x80000000 and above.

If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
within this 0x40000000-0xffffffff range. This causes the Root Port's
downstream bridge Memory Limit register to be programmed to a value >=
0x80000000.

A Root Port won't forward upstream memory transactions if the address falls
within its programmed downstream window, as it assumes it is peer-to-peer
traffic.

Could this intercept endpoint DMA targeting system memory in the overlapped
range and cause system hangs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524-lx2160-pci-v7-0-09370c23b952@solid-run.com?part=1

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Josua Mayer]

Am 24.05.26 um 17:13 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Expanding the 32-bit PCI outbound window to 3GB causes it to overlap with the inbound system memory address space, breaking DMA.
> - [High] The introduction of the 64-bit PCI memory range causes existing U-Boot bootloaders to fail device tree patching, breaking MSI and IOMMU.
> --
>
> commit a80e2e3f97808fdad781240469c5e07e019191e9
> Author: Josua Mayer <josua@solid-run.com>
>
> arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
>
> This commit extends the 32-bit PCIe memory regions to 3GB and adds 64-bit
> PCIe memory regions for LX2160A rev2. This allows allocation of large BARs
> requested by graphics processors or AI accelerators.
>
>> [4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
>> [    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
>> [    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.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)
> [Severity: High]
> Does adding the 64-bit PCI memory range cause existing U-Boot bootloaders to
> fail device tree patching?
>
> When U-Boot encounters the 64-bit range, it appears fdt_fixup_pcie() aborts
> and fails to append the msi-map and iommu-map properties.
>
> Without iommu-map, the kernel will not attach the SMMU to the PCIe devices.
> Without msi-map, the kernel cannot translate PCIe Requester IDs to ITS
> Device IDs, which breaks MSI/MSI-X allocations.
>
> Could this prevent devices like NVMe drives from initializing and break
> compatibility with existing deployed bootloaders?
This was a stray error from previous version and was resolved by passing
correct flags, as present in v7.
>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
>> index f54005e37924b..db1ebee53f6f0 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 {
>>  	      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 = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>> +		 <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>> +		 <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
> [Severity: High]
> Does expanding the 32-bit PCI outbound window to 3GB (0xc0000000) cause it to
> overlap with inbound system memory?
>
> System memory starts at physical address 0x80000000. Since there isn't a
> dma-ranges property mapping inbound DMA to a different bus address, system
> memory uses a 1:1 mapping, meaning inbound DMA targets 0x80000000 and above.
>
> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
> within this 0x40000000-0xffffffff range. This causes the Root Port's
> downstream bridge Memory Limit register to be programmed to a value >=
> 0x80000000.
>
> A Root Port won't forward upstream memory transactions if the address falls
> within its programmed downstream window, as it assumes it is peer-to-peer
> traffic.
>
> Could this intercept endpoint DMA targeting system memory in the overlapped
> range and cause system hangs?
This configuration was tested with NVMe and GPUs,
the SMMU should ensure isolation pci bus addresses do not overlap with
physical ram base address.

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Arnd Bergmann]

On Sun, May 24, 2026, at 19:12, Josua Mayer wrote:
> Am 24.05.26 um 17:13 schrieb sashiko-bot@kernel.org:

>>> -	ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>> -		  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>> +	ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>> +		 <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>> +		 <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>> [Severity: High]
>> Does expanding the 32-bit PCI outbound window to 3GB (0xc0000000) cause it to
>> overlap with inbound system memory?
>>
>> System memory starts at physical address 0x80000000. Since there isn't a
>> dma-ranges property mapping inbound DMA to a different bus address, system
>> memory uses a 1:1 mapping, meaning inbound DMA targets 0x80000000 and above.
>>
>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>> downstream bridge Memory Limit register to be programmed to a value >=
>> 0x80000000.
>>
>> A Root Port won't forward upstream memory transactions if the address falls
>> within its programmed downstream window, as it assumes it is peer-to-peer
>> traffic.
>>
>> Could this intercept endpoint DMA targeting system memory in the overlapped
>> range and cause system hangs?
> This configuration was tested with NVMe and GPUs,
> the SMMU should ensure isolation pci bus addresses do not overlap with
> physical ram base address.

I noticed the same thing while reading through the pull request
for 7.2, and I think the bot message is correct here. The SMMU
does not help here because addresses on the same bus are routed
inside of the PCIe host bridge rather than directed to the host
side. If the non-prefetchable ranges ever get assigned to an
address 0x80000000, this definitely breaks.

You will not hit this in most tests, because large MMIO windows
are likely to be 64-bit capable and will end up in the
prefetchable range and addresses are usually assigned from
the lowest address. You can try to force the bug by starting the
non-prefetchable window just below the start of RAM for testing,
which will assign some of the devices to the RAM area.

        Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Frank Li]

On 6/9/2026 12:24 PM, Arnd Bergmann wrote:
> [You don't often get email from arnd@arndb.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Sun, May 24, 2026, at 19:12, Josua Mayer wrote:
>> Am 24.05.26 um 17:13 schrieb sashiko-bot@kernel.org:
> 
>>>> -   ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>>> -             0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>>> +   ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>>> +            <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>>> +            <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>>> [Severity: High]
>>> Does expanding the 32-bit PCI outbound window to 3GB (0xc0000000) cause it to
>>> overlap with inbound system memory?
>>>
>>> System memory starts at physical address 0x80000000. Since there isn't a
>>> dma-ranges property mapping inbound DMA to a different bus address, system
>>> memory uses a 1:1 mapping, meaning inbound DMA targets 0x80000000 and above.
>>>
>>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>>> downstream bridge Memory Limit register to be programmed to a value >=
>>> 0x80000000.
>>>
>>> A Root Port won't forward upstream memory transactions if the address falls
>>> within its programmed downstream window, as it assumes it is peer-to-peer
>>> traffic.
>>>
>>> Could this intercept endpoint DMA targeting system memory in the overlapped
>>> range and cause system hangs?
>> This configuration was tested with NVMe and GPUs,
>> the SMMU should ensure isolation pci bus addresses do not overlap with
>> physical ram base address.
> 
> I noticed the same thing while reading through the pull request
> for 7.2, and I think the bot message is correct here. The SMMU
> does not help here because addresses on the same bus are routed
> inside of the PCIe host bridge rather than directed to the host
> side. If the non-prefetchable ranges ever get assigned to an
> address 0x80000000, this definitely breaks.

The address and size is 64bit,
	0x80_40000000..0x80_FFFFFFFF for 32bit non-non-prefetchable
         0x84_00000000..0x87_FFFFFFFF for 64bit prefetchable memory

AI Bot wrong think it is 32bit address and size.

Frank

> 
> You will not hit this in most tests, because large MMIO windows
> are likely to be 64-bit capable and will end up in the
> prefetchable range and addresses are usually assigned from
> the lowest address. You can try to force the bug by starting the
> non-prefetchable window just below the start of RAM for testing,
> which will assign some of the devices to the RAM area.
> 
>          Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Arnd Bergmann]

On Tue, Jun 9, 2026, at 20:01, Frank Li wrote:
> On 6/9/2026 12:24 PM, Arnd Bergmann wrote:
>> [You don't often get email from arnd@arndb.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>> -   ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>>>> -             0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>>>> +   ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>>>> +            <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>>>> +            <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>>>>
>>>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>>>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>>>> downstream bridge Memory Limit register to be programmed to a value >=
>>>> 0x80000000.
>>>>
>> 
>> I noticed the same thing while reading through the pull request
>> for 7.2, and I think the bot message is correct here. The SMMU
>> does not help here because addresses on the same bus are routed
>> inside of the PCIe host bridge rather than directed to the host
>> side. If the non-prefetchable ranges ever get assigned to an
>> address 0x80000000, this definitely breaks.
>
> The address and size is 64bit,
> 	0x80_40000000..0x80_FFFFFFFF for 32bit non-non-prefetchable
>          0x84_00000000..0x87_FFFFFFFF for 64bit prefetchable memory
>
> AI Bot wrong think it is 32bit address and size.

No, this is about the bus address, not the CPU address, and this
is given as '0x82000000 0x00 0x40000000' above. non-prefetchable
addresses on PCI are by definition 32-bit, so the middle cell
is zero.

On the CPU side, this is mapped to physical '0x80 0x40000000',
which does not overlap with CPUs view of RAM, but the
bus view of 0x40000000-0xffffffff does overlap with the
DMA address for the lower 2GB of RAM at 0x80000000-0xffffffff.

     Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Frank Li]

On 6/9/2026 2:36 PM, Arnd Bergmann wrote:
> [You don't often get email from arnd@arndb.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Tue, Jun 9, 2026, at 20:01, Frank Li wrote:
>> On 6/9/2026 12:24 PM, Arnd Bergmann wrote:
>>> [You don't often get email from arnd@arndb.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>> -   ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>>>>> -             0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>>>>> +   ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>>>>> +            <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>>>>> +            <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>>>>>
>>>>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>>>>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>>>>> downstream bridge Memory Limit register to be programmed to a value >=
>>>>> 0x80000000.
>>>>>
>>>
>>> I noticed the same thing while reading through the pull request
>>> for 7.2, and I think the bot message is correct here. The SMMU
>>> does not help here because addresses on the same bus are routed
>>> inside of the PCIe host bridge rather than directed to the host
>>> side. If the non-prefetchable ranges ever get assigned to an
>>> address 0x80000000, this definitely breaks.
>>
>> The address and size is 64bit,
>>        0x80_40000000..0x80_FFFFFFFF for 32bit non-non-prefetchable
>>           0x84_00000000..0x87_FFFFFFFF for 64bit prefetchable memory
>>
>> AI Bot wrong think it is 32bit address and size.
> 
> No, this is about the bus address, not the CPU address, and this
> is given as '0x82000000 0x00 0x40000000' above. non-prefetchable
> addresses on PCI are by definition 32-bit, so the middle cell
> is zero.
> 
> On the CPU side, this is mapped to physical '0x80 0x40000000',
> which does not overlap with CPUs view of RAM, but the
> bus view of 0x40000000-0xffffffff does overlap with the
> DMA address for the lower 2GB of RAM at 0x80000000-0xffffffff.

This is pci TLP bus address, which will not appear in internal fabric at
all.  That is PCI TLP address, which is totally separated addr space and 
can be any address.


        in SOC                                  |  PCB boards rx/tx
==================================================================
CPU address                 PCI controller     |   PCI bus
80_40000000..0x80_FFFFFFFF    ATU              |    0x4000_0000

writel(80_40000000), PCIe controller will convert to 0x4000_0000 and
sendout TLP package memw addr 0x4000_0000, which already go out SoC. EP 
device like wifi, will decode 0x4000_0000 to do related work.

In side SoC, no one can see tlp:0x4000_0000, which only visual by PCI EP
devices, which means only connect EP device decode this address.

Additional information:
In bound address space (from EP to RC) is not controlled by ranges, but
dma-ranges.

Frank


> 
>       Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Arnd Bergmann]

On Tue, Jun 9, 2026, at 22:34, Frank Li wrote:
> On 6/9/2026 2:36 PM, Arnd Bergmann wrote:
>> On Tue, Jun 9, 2026, at 20:01, Frank Li wrote:
>>> On 6/9/2026 12:24 PM, Arnd Bergmann wrote:
>>>> [You don't often get email from arnd@arndb.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>> -   ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>>>>>> -             0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>>>>>> +   ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>>>>>> +            <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>>>>>> +            <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>>>>>>
>>>>>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>>>>>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>>>>>> downstream bridge Memory Limit register to be programmed to a value >=
>>>>>> 0x80000000.
>>>>>>
>>>>
>>>> I noticed the same thing while reading through the pull request
>>>> for 7.2, and I think the bot message is correct here. The SMMU
>>>> does not help here because addresses on the same bus are routed
>>>> inside of the PCIe host bridge rather than directed to the host
>>>> side. If the non-prefetchable ranges ever get assigned to an
>>>> address 0x80000000, this definitely breaks.
>>>
>>> The address and size is 64bit,
>>>        0x80_40000000..0x80_FFFFFFFF for 32bit non-non-prefetchable
>>>           0x84_00000000..0x87_FFFFFFFF for 64bit prefetchable memory
>>>
>>> AI Bot wrong think it is 32bit address and size.
>> 
>> No, this is about the bus address, not the CPU address, and this
>> is given as '0x82000000 0x00 0x40000000' above. non-prefetchable
>> addresses on PCI are by definition 32-bit, so the middle cell
>> is zero.
>> 
>> On the CPU side, this is mapped to physical '0x80 0x40000000',
>> which does not overlap with CPUs view of RAM, but the
>> bus view of 0x40000000-0xffffffff does overlap with the
>> DMA address for the lower 2GB of RAM at 0x80000000-0xffffffff.
>
> This is pci TLP bus address, which will not appear in internal fabric at
> all.  That is PCI TLP address, which is totally separated addr space and 
> can be any address.
>
>
>         in SOC                                  |  PCB boards rx/tx
> ==================================================================
> CPU address                 PCI controller     |   PCI bus
> 80_40000000..0x80_FFFFFFFF    ATU              |    0x4000_0000
>
> writel(80_40000000), PCIe controller will convert to 0x4000_0000 and
> sendout TLP package memw addr 0x4000_0000, which already go out SoC. EP 
> device like wifi, will decode 0x4000_0000 to do related work.
>
> In side SoC, no one can see tlp:0x4000_0000, which only visual by PCI EP
> devices, which means only connect EP device decode this address.
>
> Additional information:
> In bound address space (from EP to RC) is not controlled by ranges, but
> dma-ranges.

The scenario I'm describing is a device initiated TLP that is directed
at memory in the first 4GiB of addresses, e.g. 0x8000_0000.  If any
PCIe function on the same host bridge has a non-prefetchable BAR
assigned to 0x8000_0000, the transfer should normally hit this
BAR as a P2P transfer, unless ACS forces the transfer out towards
the IOMMU.

If ACS is guaranteed to always be enabled on this machine, it's
probably fine, as that would route (intentional) P2P transfers through 
the IOMMU, which can remap the destination BAR to an available
bus address.

    Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Frank Li]

On 6/9/2026 4:31 PM, Arnd Bergmann wrote:
> On Tue, Jun 9, 2026, at 22:34, Frank Li wrote:
>> On 6/9/2026 2:36 PM, Arnd Bergmann wrote:
>>> On Tue, Jun 9, 2026, at 20:01, Frank Li wrote:
>>>> On 6/9/2026 12:24 PM, Arnd Bergmann wrote:
>>>>> [You don't often get email from arnd@arndb.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>>> -   ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>>>>>>>> -             0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>>>>>>>> +   ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>>>>>>>> +            <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>>>>>>>> +            <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
>>>>>>>
>>>>>>> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
>>>>>>> within this 0x40000000-0xffffffff range. This causes the Root Port's
>>>>>>> downstream bridge Memory Limit register to be programmed to a value >=
>>>>>>> 0x80000000.
>>>>>>>
>>>>>
>>>>> I noticed the same thing while reading through the pull request
>>>>> for 7.2, and I think the bot message is correct here. The SMMU
>>>>> does not help here because addresses on the same bus are routed
>>>>> inside of the PCIe host bridge rather than directed to the host
>>>>> side. If the non-prefetchable ranges ever get assigned to an
>>>>> address 0x80000000, this definitely breaks.
>>>>
>>>> The address and size is 64bit,
>>>>         0x80_40000000..0x80_FFFFFFFF for 32bit non-non-prefetchable
>>>>            0x84_00000000..0x87_FFFFFFFF for 64bit prefetchable memory
>>>>
>>>> AI Bot wrong think it is 32bit address and size.
>>>
>>> No, this is about the bus address, not the CPU address, and this
>>> is given as '0x82000000 0x00 0x40000000' above. non-prefetchable
>>> addresses on PCI are by definition 32-bit, so the middle cell
>>> is zero.
>>>
>>> On the CPU side, this is mapped to physical '0x80 0x40000000',
>>> which does not overlap with CPUs view of RAM, but the
>>> bus view of 0x40000000-0xffffffff does overlap with the
>>> DMA address for the lower 2GB of RAM at 0x80000000-0xffffffff.
>>
>> This is pci TLP bus address, which will not appear in internal fabric at
>> all.  That is PCI TLP address, which is totally separated addr space and
>> can be any address.
>>
>>
>>          in SOC                                  |  PCB boards rx/tx
>> ==================================================================
>> CPU address                 PCI controller     |   PCI bus
>> 80_40000000..0x80_FFFFFFFF    ATU              |    0x4000_0000
>>
>> writel(80_40000000), PCIe controller will convert to 0x4000_0000 and
>> sendout TLP package memw addr 0x4000_0000, which already go out SoC. EP
>> device like wifi, will decode 0x4000_0000 to do related work.
>>
>> In side SoC, no one can see tlp:0x4000_0000, which only visual by PCI EP
>> devices, which means only connect EP device decode this address.
>>
>> Additional information:
>> In bound address space (from EP to RC) is not controlled by ranges, but
>> dma-ranges.
> 
> The scenario I'm describing is a device initiated TLP that is directed
> at memory in the first 4GiB of addresses, e.g. 0x8000_0000.  If any
> PCIe function on the same host bridge has a non-prefetchable BAR
> assigned to 0x8000_0000, the transfer should normally hit this
> BAR as a P2P transfer, unless ACS forces the transfer out towards
> the IOMMU.

Finally I understand your means. This dwc controller actually only
have ONE port. All inbound transfer will go though internal bus fabric.

inbound transfer -> PCIE controller -> bus fabric -> ddr/other pcie 
controller.

If fabric allow this kinds route (I am not sure configuration for this
SOC), the address must be 8x_40000000 to route to another PCIe controller.

If EP itself is PCIe bridge, it may be problem. It'd better to
keep 32bit range unchange.

Do you need rework pull request?  Or you can drop this patch.

Frank
> 
> If ACS is guaranteed to always be enabled on this machine, it's
> probably fine, as that would route (intentional) P2P transfers through
> the IOMMU, which can remap the destination BAR to an available
> bus address.
> 
>      Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Arnd Bergmann]

On Wed, Jun 10, 2026, at 00:13, Frank Li wrote:
> On 6/9/2026 4:31 PM, Arnd Bergmann wrote:
>
> If EP itself is PCIe bridge, it may be problem. It'd better to
> keep 32bit range unchange.

Ok. It is not uncommon to have PCIe bridges either in physical
form, or inside of devices that have multiple PCIe functions,
so this does seem like a real problem to me even when more commonly
you'd only have a single PCIe function with a single memory BAR
on each host bridge.

> Do you need rework pull request?  Or you can drop this patch.

I can't easily drop the commit without losing your signed tag
on the pull request. Please update the pull request to either
drop this on your end or add a fixup patch on top that reverts
to a 1GB non-prefetchable window for each of the controllers.

On a related note, please make sure that you don't send
a large series like this late in the development cycle
so we have enough time to resolve any issues that may come
up. You can also send a follow-up pull request with last
minute fixups and changes that were still waiting for
review. The bulk of the branch contents look like they 
have been stable for a while, so the best thing would have
been to send those in a first PR.

If everything goes well otherwise, this PR should still make
it in time, but it would be nice to avoid such minute
excitement in the future.

       Arnd

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Josua Mayer]

Hi Arnd, Frank,

Am 10.06.26 um 09:43 schrieb Arnd Bergmann:
> On Wed, Jun 10, 2026, at 00:13, Frank Li wrote:
>> On 6/9/2026 4:31 PM, Arnd Bergmann wrote:
>>
>> If EP itself is PCIe bridge, it may be problem. It'd better to
>> keep 32bit range unchange.
> Ok. It is not uncommon to have PCIe bridges either in physical
> form, or inside of devices that have multiple PCIe functions,
> so this does seem like a real problem to me even when more commonly
> you'd only have a single PCIe function with a single memory BAR
> on each host bridge.
>
>> Do you need rework pull request?  Or you can drop this patch.
> I can't easily drop the commit without losing your signed tag
> on the pull request. Please update the pull request to either
> drop this on your end or add a fixup patch on top that reverts
> to a 1GB non-prefetchable window for each of the controllers.
>
> On a related note, please make sure that you don't send
> a large series like this late in the development cycle
> so we have enough time to resolve any issues that may come
> up. You can also send a follow-up pull request with last
> minute fixups and changes that were still waiting for
> review. The bulk of the branch contents look like they 
> have been stable for a while, so the best thing would have
> been to send those in a first PR.
>
> If everything goes well otherwise, this PR should still make
> it in time, but it would be nice to avoid such minute
> excitement in the future.

Thank you for discussing this issue in detail!

If you need me to send a fixup, kindly let me know.

Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions

[Arnd Bergmann]

On Wed, Jun 10, 2026, at 12:36, Josua Mayer wrote:
> Am 10.06.26 um 09:43 schrieb Arnd Bergmann:
>> On Wed, Jun 10, 2026, at 00:13, Frank Li wrote:
>>
>> If everything goes well otherwise, this PR should still make
>> it in time, but it would be nice to avoid such minute
>> excitement in the future.
>
> Thank you for discussing this issue in detail!
>
> If you need me to send a fixup, kindly let me know.

I think that would be best, yes. Then Frank can apply
the patch on top and send the updated pull request.

      Arnd

[PATCH v7 2/9] arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi

[Josua Mayer]

LX2160A and LX2162A are different pakages of the same silicon.
While LX2160A had two revisions, LX2162A was released later based on
LX2160A revision 2.

Commit a8fe6c8dfc40 ("arm64: dts: fsl-lx2160a: add rev2 support") has
added a new soc dtsi for revision 2.

Update LX2162A Clearfog description to use revision 2 dtsi.

Fixes: 5093b190f9ce ("arm64: dts: freescale: Add support for LX2162 SoM & Clearfog Board") # no-stable
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 9d50d3e2761da..f95e9c19bfc75 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -6,7 +6,7 @@
 
 /dts-v1/;
 
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-rev2.dtsi"
 #include "fsl-lx2162a-sr-som.dtsi"
 
 / {

-- 
2.51.0

[PATCH v7 3/9] arm64: dts: lx2162a-clearfog: cleanup superfluous status properties

[Josua Mayer]

The SoC dtsi has always enabled serdes block 1, enabled dpmac and
disabled pcie nodes.

Drop the superfluous status properties on these nodes.

Further drop crypto alias as SoM dtsi already set it.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 .../boot/dts/freescale/fsl-lx2162a-clearfog.dts     | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index f95e9c19bfc75..6fd85a5cac94e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -14,7 +14,6 @@ / {
 	compatible = "solidrun,lx2162a-clearfog", "solidrun,lx2162a-som", "fsl,lx2160a";
 
 	aliases {
-		crypto = &crypto;
 		i2c0 = &i2c0;
 		i2c1 = &i2c2;
 		i2c2 = &i2c4;
@@ -124,42 +123,36 @@ &dpmac11 {
 	phys = <&serdes_2 0>;
 	phy-handle = <&ethernet_phy3>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac12 {
 	phys = <&serdes_2 1>;
 	phy-handle = <&ethernet_phy1>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac13 {
 	phys = <&serdes_2 6>;
 	phy-handle = <&ethernet_phy6>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac14 {
 	phys = <&serdes_2 7>;
 	phy-handle = <&ethernet_phy8>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac15 {
 	phys = <&serdes_2 4>;
 	phy-handle = <&ethernet_phy4>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac16 {
 	phys = <&serdes_2 5>;
 	phy-handle = <&ethernet_phy2>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac17 {
@@ -170,14 +163,12 @@ &dpmac17 {
 	phys = <&serdes_2 2>;
 	phy-handle = <&ethernet_phy5>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &dpmac18 {
 	phys = <&serdes_2 3>;
 	phy-handle = <&ethernet_phy7>;
 	phy-connection-type = "sgmii";
-	status = "okay";
 };
 
 &emdio1 {
@@ -314,14 +305,6 @@ pcieclk_i2c: i2c@2 {
 	};
 };
 
-&pcie3 {
-	status = "disabled";
-};
-
-&pcie4 {
-	status = "disabled";
-};
-
 &pcs_mdio3 {
 	status = "okay";
 };
@@ -370,10 +353,6 @@ &pcs_mdio18 {
 	status = "okay";
 };
 
-&serdes_1 {
-	status = "okay";
-};
-
 &serdes_2 {
 	status = "okay";
 };

-- 
2.51.0

[PATCH v7 4/9] arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function

[Josua Mayer]

The LX2162A Clearfog board has a green LED on each of four SFP ports.

Describe in device-tree that their colour is green and function "lan".

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 6fd85a5cac94e..99ee2b1c0f13b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -6,6 +6,8 @@
 
 /dts-v1/;
 
+#include <dt-bindings/leds/common.h>
+
 #include "fsl-lx2160a-rev2.dtsi"
 #include "fsl-lx2162a-sr-som.dtsi"
 
@@ -38,6 +40,9 @@ leds {
 		compatible = "gpio-leds";
 
 		led_sfp_at: led-sfp-at {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <1>;
 			gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* PROC_IRQ5 */
 			default-state = "off";
 			linux,default-trigger = "netdev";
@@ -45,6 +50,9 @@ led_sfp_at: led-sfp-at {
 		};
 
 		led_sfp_ab: led-sfp-ab {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <2>;
 			gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>; /* PROC_IRQ11 */
 			default-state = "off";
 			linux,default-trigger = "netdev";
@@ -52,6 +60,9 @@ led_sfp_ab: led-sfp-ab {
 		};
 
 		led_sfp_bt: led-sfp-bt {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <3>;
 			gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; /* EVT1_B */
 			default-state = "off";
 			linux,default-trigger = "netdev";
@@ -59,6 +70,9 @@ led_sfp_bt: led-sfp-bt {
 		};
 
 		led_sfp_bb: led-sfp-bb {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <4>;
 			gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; /* EVT2_B */
 			default-state = "off";
 			linux,default-trigger = "netdev";

-- 
2.51.0

[PATCH v7 5/9] dt-bindings: arm: fsl: Add solidrun lx2160a twins board

[Josua Mayer]

The SolidRun LX2160A Twins board supports two configurations, one with
with a single CEX-7 module, and one with two (dual).

The single configuration is a specific assembly that maximises
connectivity for single cpu by routing some second cpu resources to the
first via zero-Ohm resistors.

The dual configuration was not yet tested and is intentionally omitted.

Initial review strongly suggests that the dual configuration will have
different bindings, because from either cpu point of view the board
appears different (e.g. different number of sfp, fewer i2c gpio).

Add binding for the single variant only.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0023cd1268075..1f11c1208c248 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1868,6 +1868,7 @@ properties:
           - enum:
               - solidrun,clearfog-cx
               - solidrun,honeycomb
+              - solidrun,twins-single
           - const: solidrun,lx2160a-cex7
           - const: fsl,lx2160a
 

-- 
2.51.0

Re: [PATCH v7 5/9] dt-bindings: arm: fsl: Add solidrun lx2160a twins board

[Krzysztof Kozlowski]

On Sun, May 24, 2026 at 04:54:44PM +0200, Josua Mayer wrote:
> The SolidRun LX2160A Twins board supports two configurations, one with
> with a single CEX-7 module, and one with two (dual).
> 
> The single configuration is a specific assembly that maximises
> connectivity for single cpu by routing some second cpu resources to the
> first via zero-Ohm resistors.
> 
> The dual configuration was not yet tested and is intentionally omitted.
> 
> Initial review strongly suggests that the dual configuration will have
> different bindings, because from either cpu point of view the board
> appears different (e.g. different number of sfp, fewer i2c gpio).
> 
> Add binding for the single variant only.
> 
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH v7 6/9] arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag

[Josua Mayer]

The dts version tag should only appear in the top level dts file.

Since the cex-7 module and clearfog-itx are shared code intended for
inclusion, drop their dts version tags.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi         | 2 --
 arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 2 --
 2 files changed, 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 90956ffb8ea9a..56b74837ddd48 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -4,8 +4,6 @@
 //
 // Copyright 2019 SolidRun Ltd.
 
-/dts-v1/;
-
 #include "fsl-lx2160a.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 580ee9b3026e3..6388bd60ffdf5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -5,8 +5,6 @@
 //
 // Copyright 2019 SolidRun Ltd.
 
-/dts-v1/;
-
 #include "fsl-lx2160a-cex7.dtsi"
 #include <dt-bindings/input/linux-event-codes.h>
 

-- 
2.51.0

[PATCH v7 7/9] arm64: dts: lx2160a-clearfog-itx: move shared includes to dts

[Josua Mayer]

Originally includes were defined hierarchically:
- CEX-7 Module includes SoC
- Clearfog-CX & Honeycomb common parts include CEX-7 Module
- Boards include common parts

This makes it difficult to modify the includes on a per-board level,
e.g. when adding a new board based on CEX-7 module but revision 2 SoC
(which now has its own soc dtsi).

Move includes of both SoC and CEX-7 module out of common parts and into
each board dts.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi         | 2 --
 arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts   | 2 ++
 arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 1 -
 arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts     | 2 ++
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 56b74837ddd48..7df93bb37d13c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -4,8 +4,6 @@
 //
 // Copyright 2019 SolidRun Ltd.
 
-#include "fsl-lx2160a.dtsi"
-
 / {
 	model = "SolidRun LX2160A COM Express Type 7 module";
 	compatible = "solidrun,lx2160a-cex7", "fsl,lx2160a";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
index 86a9b771428dc..802d7611c6479 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
@@ -6,6 +6,8 @@
 
 /dts-v1/;
 
+#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-cex7.dtsi"
 #include "fsl-lx2160a-clearfog-itx.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 6388bd60ffdf5..170e5b0034f19 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -5,7 +5,6 @@
 //
 // Copyright 2019 SolidRun Ltd.
 
-#include "fsl-lx2160a-cex7.dtsi"
 #include <dt-bindings/input/linux-event-codes.h>
 
 / {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
index fe19f3009ea58..2b1e13053422b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
@@ -6,6 +6,8 @@
 
 /dts-v1/;
 
+#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-cex7.dtsi"
 #include "fsl-lx2160a-clearfog-itx.dtsi"
 
 / {

-- 
2.51.0

[PATCH v7 8/9] arm64: dts: lx2160a-cex7: add usb hub

[Josua Mayer]

LX2160A CEX-7 module provides a total of 4 USB ports to the carrier
board, one from first usb controller, and 3 from a hub behind the second
controller.

Both controllers currently have their status set okay in the module's
dtsi file. However devices should be disabled by default when
incomplete.

The first USB controller is only completed by a carrier board featuring
a device or USB connector.

The second controller hosts a USB hub and should therefore be active.

Add description for the USB hub, and enable the first controller only in
the carrier board description.

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 .../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 29 +++++++++++++++++++---
 .../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi    |  4 +++
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 7df93bb37d13c..2c86734c39ab2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -13,6 +13,13 @@ aliases {
 		rtc0 = &com_rtc;
 	};
 
+	v_1_2: regulator-1-2 {
+		compatible = "regulator-fixed";
+		regulator-name = "1v2";
+		regulator-max-microvolt = <1200000>;
+		regulator-min-microvolt = <1200000>;
+	};
+
 	sb_3v3: regulator-sb3v3 {
 		compatible = "regulator-fixed";
 		regulator-name = "RT7290";
@@ -181,10 +188,24 @@ &pinmux_i2crv {
 	pinctrl-0 = <&gpio0_14_12_pins>;
 };
 
-&usb0 {
-	status = "okay";
-};
-
 &usb1 {
+	#address-cells = <1>;
+	#size-cells = <0>;
 	status = "okay";
+
+	usb_hub_2_0: hub@1 {
+		compatible = "usb4b4,6502", "usb4b4,6506";
+		reg = <1>;
+		peer-hub = <&usb_hub_3_0>;
+		vdd2-supply = <&sb_3v3>;
+		vdd-supply = <&v_1_2>;
+	};
+
+	usb_hub_3_0: hub@2 {
+		compatible = "usb4b4,6500", "usb4b4,6504";
+		reg = <2>;
+		peer-hub = <&usb_hub_2_0>;
+		vdd2-supply = <&sb_3v3>;
+		vdd-supply = <&v_1_2>;
+	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 170e5b0034f19..4bc151d721ddf 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -142,3 +142,7 @@ &uart0 {
 &uart1 {
 	status = "okay";
 };
+
+&usb0 {
+	status = "okay";
+};

-- 
2.51.0

[PATCH v7 9/9] arm64: dts: Add support for LX2160 Twins board in single configuration

[Josua Mayer]

Add support for the SolidRun LX2160A Twins board in its single cpu
configuration.

The twins board is designed to host a pair of LX2160A CEX-7 modules,
sharing a single PCI-E connector in multi-host mode.

It may be assembled in two configurations (different assembly options
facilitating signal re-routing), with a single or with dual CEX-7
module. Their marketing names are:

- SolidWAN Single LX2160
- SolidWAN Dual LX2160

This patch adds the single configuration, featuring:
- 8x SFP (1Gbps)
- 8x SFP+ (1/10Gbps)
- PCI-E OCP card connector
- USB-3.0 front-panel header with single port
- microSD
- dual hot-swappable power supplies

Signed-off-by: Josua Mayer <josua@solid-run.com>
---
 arch/arm64/boot/dts/freescale/Makefile             |   2 +
 .../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi |   8 +-
 .../boot/dts/freescale/fsl-lx2160a-half-twins.dts  | 830 +++++++++++++++++++++
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi     |  24 +-
 4 files changed, 848 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c990..59eee431562ef 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -51,6 +51,8 @@ DTC_FLAGS_fsl-lx2160a-bluebox3-rev-a := -Wno-interrupt_map
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-bluebox3-rev-a.dtb
 DTC_FLAGS_fsl-lx2160a-clearfog-cx := -Wno-interrupt_map
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-clearfog-cx.dtb
+DTC_FLAGS_fsl-lx2160a-half-twins := -Wno-interrupt_map
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-half-twins.dtb
 DTC_FLAGS_fsl-lx2160a-honeycomb := -Wno-interrupt_map
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb
 DTC_FLAGS_fsl-lx2160a-qds := -Wno-interrupt_map
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 2c86734c39ab2..16caa281ece02 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -65,7 +65,7 @@ i2c-mux@77 {
 		#size-cells = <0>;
 		reg = <0x77>;
 
-		i2c@0 {
+		ddr_i2c: i2c@0 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0>;
@@ -91,7 +91,7 @@ eeprom@57 {
 			};
 		};
 
-		i2c@1 {
+		fan_i2c: i2c@1 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <1>;
@@ -102,7 +102,7 @@ fan-temperature-ctrlr@18 {
 			};
 		};
 
-		i2c@2 {
+		power_i2c: i2c@2 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <2>;
@@ -113,7 +113,7 @@ regulator@5c {
 			};
 		};
 
-		i2c@3 {
+		i2c_smb: i2c@3 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <3>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
new file mode 100644
index 0000000000000..d16e273072754
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
@@ -0,0 +1,830 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file for single LX2160A CEX-7 on Twins board.
+//
+// Copyright 2022 SolidRun Ltd.
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+
+#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2160a-cex7.dtsi"
+
+/ {
+	compatible = "solidrun,twins-single", "solidrun,lx2160a-cex7", "fsl,lx2160a";
+	model = "SolidRun LX2160A SolidWAN Single";
+
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &expander0;
+		gpio5 = &expander1;
+		gpio6 = &expander2;
+		gpio7 = &expander3;
+		i2c0 = &i2c0;
+		i2c1 = &i2c2;
+		i2c2 = &i2c4;
+		i2c3 = &fan_i2c;
+		i2c4 = &power_i2c;
+		i2c5 = &i2c_smb;
+		i2c6 = &sfp0_i2c;
+		i2c7 = &sfp1_i2c;
+		i2c8 = &sfp2_i2c;
+		i2c9 = &sfp3_i2c;
+		i2c10 = &twins_sfp_c1_at_i2c;
+		i2c11 = &twins_sfp_c1_ab_i2c;
+		i2c12 = &twins_sfp_c1_bt_i2c;
+		i2c13 = &twins_sfp_c1_bb_i2c;
+		i2c14 = &twins_sfp_c2_at_i2c;
+		i2c15 = &twins_sfp_c2_ab_i2c;
+		i2c16 = &twins_sfp_c2_bt_i2c;
+		i2c17 = &twins_sfp_c2_bb_i2c;
+		i2c18 = &twins_sfp_c3_at_i2c;
+		i2c19 = &twins_sfp_c3_ab_i2c;
+		i2c20 = &twins_sfp_c3_bt_i2c;
+		i2c21 = &twins_sfp_c3_bb_i2c;
+		i2c22 = &htwins_sfp_c3_at_i2c;
+		i2c23 = &htwins_sfp_c3_ab_i2c;
+		i2c24 = &htwins_sfp_c3_bt_i2c;
+		i2c25 = &htwins_sfp_c3_bb_i2c;
+		i2c26 = &ddr_i2c;
+		mmc0 = &esdhc0;
+		mmc1 = &esdhc1;
+		serial0 = &uart0;
+		serial1 = &uart1;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led_ht_c3_bt: led-sfp-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <1>;
+			gpios = <&expander3 14 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac5>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_ht_c3_bb: led-sfp-2 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <2>;
+			gpios = <&expander3 13 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac15>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_ht_c3_at: led-sfp-3 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <3>;
+			gpios = <&expander3 11 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac6>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_ht_c3_ab: led-sfp-4 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <4>;
+			gpios = <&expander3 12 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac11>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c1_bt: led-sfp-9 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <9>;
+			gpios = <&expander1 4 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac4>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c1_bb: led-sfp-10 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <10>;
+			gpios = <&expander1 3 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac17>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c1_at: led-sfp-11 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <11>;
+			gpios = <&expander1 1 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac3>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c1_ab: led-sfp-12 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <12>;
+			gpios = <&expander1 2 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac12>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c2_bt: led-sfp-13 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <13>;
+			gpios = <&expander1 10 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac8>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c2_bb: led-sfp-14 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <14>;
+			gpios = <&expander1 9 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac16>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c2_at: led-sfp-15 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <15>;
+			gpios = <&expander1 5 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac7>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c2_ab: led-sfp-16 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <16>;
+			gpios = <&expander1 6 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac18>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c3_bt: led-sfp-17 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <17>;
+			gpios = <&expander1 14 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac10>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c3_bb: led-sfp-18 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <18>;
+			gpios = <&expander1 13 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac14>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c3_at: led-sfp-19 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <19>;
+			gpios = <&expander1 11 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac9>;
+			linux,default-trigger = "netdev";
+		};
+
+		led_c3_ab: led-sfp-20 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_LAN;
+			function-enumerator = <20>;
+			gpios = <&expander1 12 GPIO_ACTIVE_LOW>;
+			trigger-sources = <&dpmac13>;
+			linux,default-trigger = "netdev";
+		};
+
+		led-status {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_STATUS;
+			function-enumerator = <0>;
+			gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-status-twin {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_STATUS;
+			function-enumerator = <1>;
+			gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+		};
+
+		led-fault {
+			color = <LED_COLOR_ID_YELLOW>;
+			default-state = "off";
+			function = LED_FUNCTION_FAULT;
+			function-enumerator = <0>;
+			gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+			panic-indicator;
+		};
+
+		led-fault-twin {
+			color = <LED_COLOR_ID_YELLOW>;
+			default-state = "off";
+			function = LED_FUNCTION_FAULT;
+			function-enumerator = <1>;
+			gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	mux-controller {
+		compatible = "gpio-mux";
+		#mux-control-cells = <0>;
+		/*
+		 * This gpio controlled mux can route the tacho signals of 6 PWM FAN connectors
+		 * to the tacho inputs of both CEX-7 modules (twins).
+		 *
+		 * The first twin controls this mux and monitors four fan connectors, two intended
+		 * for itself, and two for the OCP card.
+		 *
+		 * The second twin monitors only two fan connectors intended for itself.
+		 *
+		 * The table below maps selector GPIO states to monitored fan connector per twin:
+		 *
+		 * | SEL1 | SEL0 | Twin 1 | Twin 2 |
+		 * | ---: | ---: | :------| ------ |
+		 * |    0 |    0 | J10    |  J5024 |
+		 * |    0 |    1 | J5016  |  J5024 |
+		 * |    1 |    0 | J5026  |  J5025 |
+		 * |    1 |    1 | J5013  |  J5025 |
+		 */
+		mux-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>, /* SEL0 */
+			    <&expander0 15 GPIO_ACTIVE_HIGH>; /* SEL1 */
+	};
+
+	ht_c3_bt_sfp: sfp-1 {
+		compatible = "sff,sfp";
+		i2c-bus = <&htwins_sfp_c3_bt_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander2 13 GPIO_ACTIVE_LOW>;
+	};
+
+	ht_c3_bb_sfp: sfp-2 {
+		compatible = "sff,sfp";
+		i2c-bus = <&htwins_sfp_c3_bb_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander2 14 GPIO_ACTIVE_LOW>;
+	};
+
+	ht_c3_at_sfp: sfp-3 {
+		compatible = "sff,sfp";
+		i2c-bus = <&htwins_sfp_c3_at_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander2 11 GPIO_ACTIVE_LOW>;
+	};
+
+	ht_c3_ab_sfp: sfp-4 {
+		compatible = "sff,sfp";
+		i2c-bus = <&htwins_sfp_c3_ab_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander2 12 GPIO_ACTIVE_LOW>;
+	};
+
+	c1_bt_sfp: sfp-9 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c1_bt_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 3 GPIO_ACTIVE_LOW>;
+	};
+
+	c1_bb_sfp: sfp-10 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c1_bb_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 4 GPIO_ACTIVE_LOW>;
+	};
+
+	c1_at_sfp: sfp-11 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c1_at_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 1 GPIO_ACTIVE_LOW>;
+	};
+
+	c1_ab_sfp: sfp-12 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c1_ab_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 2 GPIO_ACTIVE_LOW>;
+	};
+
+	c2_bt_sfp: sfp-13 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c2_bt_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 9 GPIO_ACTIVE_LOW>;
+	};
+
+	c2_bb_sfp: sfp-14 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c2_bb_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 10 GPIO_ACTIVE_LOW>;
+	};
+
+	c2_at_sfp: sfp-15 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c2_at_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+	};
+
+	c2_ab_sfp: sfp-16 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c2_ab_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 6 GPIO_ACTIVE_LOW>;
+	};
+
+	c3_bt_sfp: sfp-17 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c3_bt_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 13 GPIO_ACTIVE_LOW>;
+	};
+
+	c3_bb_sfp: sfp-18 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c3_bb_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 14 GPIO_ACTIVE_LOW>;
+	};
+
+	c3_at_sfp: sfp-19 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c3_at_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 11 GPIO_ACTIVE_LOW>;
+	};
+
+	c3_ab_sfp: sfp-20 {
+		compatible = "sff,sfp";
+		i2c-bus = <&twins_sfp_c3_ab_i2c>;
+		maximum-power-milliwatt = <2000>;
+		mod-def0-gpios = <&expander0 12 GPIO_ACTIVE_LOW>;
+	};
+};
+
+/*
+ * This board supports industrial grade temperatures,
+ * the LX2160A SoC maximum junction temperature is 105°C.
+ *
+ * Raise thermal thresholds to allow operation near maximum temperature.
+ */
+&ccn_dpaa_alert {
+	temperature = <100000>;
+};
+
+&ccn_dpaa_crit {
+	temperature = <105000>;
+};
+
+&cluster2_3_alert {
+	temperature = <100000>;
+};
+
+&cluster2_3_crit {
+	temperature = <105000>;
+};
+
+&cluster4_alert {
+	temperature = <100000>;
+};
+
+&cluster4_crit {
+	temperature = <105000>;
+};
+
+&cluster5_alert {
+	temperature = <100000>;
+};
+
+&cluster5_crit {
+	temperature = <105000>;
+};
+
+&cluster6_7_alert {
+	temperature = <100000>;
+};
+
+&cluster6_7_crit {
+	temperature = <105000>;
+};
+
+&dce_qbman_alert {
+	temperature = <100000>;
+};
+
+&dce_qbman_crit {
+	temperature = <105000>;
+};
+
+/* sfp port 11 */
+&dpmac3 {
+	managed = "in-band-status";
+	phys = <&serdes_1 7>;
+	sfp = <&c1_at_sfp>;
+};
+
+/* sfp port 9 */
+&dpmac4 {
+	managed = "in-band-status";
+	phys = <&serdes_1 6>;
+	sfp = <&c1_bt_sfp>;
+};
+
+/* sfp port 1 */
+&dpmac5 {
+	managed = "in-band-status";
+	phys = <&serdes_1 5>;
+	sfp = <&ht_c3_bt_sfp>;
+};
+
+/* sfp port 3 */
+&dpmac6 {
+	managed = "in-band-status";
+	phys = <&serdes_1 4>;
+	sfp = <&ht_c3_at_sfp>;
+};
+
+/* sfp port 15 */
+&dpmac7 {
+	managed = "in-band-status";
+	phys = <&serdes_1 3>;
+	sfp = <&c2_at_sfp>;
+};
+
+/* sfp port 13 */
+&dpmac8 {
+	managed = "in-band-status";
+	phys = <&serdes_1 2>;
+	sfp = <&c2_bt_sfp>;
+};
+
+/* sfp port 19 */
+&dpmac9 {
+	managed = "in-band-status";
+	phys = <&serdes_1 1>;
+	sfp = <&c3_at_sfp>;
+};
+
+/* sfp port 17 */
+&dpmac10 {
+	managed = "in-band-status";
+	phys = <&serdes_1 0>;
+	sfp = <&c3_bt_sfp>;
+};
+
+/* sfp port 4 */
+&dpmac11 {
+	managed = "in-band-status";
+	phys = <&serdes_2 0>;
+	sfp = <&ht_c3_ab_sfp>;
+};
+
+/* sfp port 12 */
+&dpmac12 {
+	managed = "in-band-status";
+	phys = <&serdes_2 1>;
+	sfp = <&c1_ab_sfp>;
+};
+
+/* sfp port 20 */
+&dpmac13 {
+	managed = "in-band-status";
+	phys = <&serdes_2 6>;
+	sfp = <&c3_ab_sfp>;
+};
+
+/* sfp port 18 */
+&dpmac14 {
+	managed = "in-band-status";
+	phys = <&serdes_2 7>;
+	sfp = <&c3_bb_sfp>;
+};
+
+/* sfp port 2 */
+&dpmac15 {
+	managed = "in-band-status";
+	phys = <&serdes_2 4>;
+	sfp = <&ht_c3_bb_sfp>;
+};
+
+/* sfp port 14 */
+&dpmac16 {
+	managed = "in-band-status";
+	phys = <&serdes_2 5>;
+	sfp = <&c2_bb_sfp>;
+};
+
+/* sfp port 10 */
+&dpmac17 {
+	/* override connection to on-COM phy */
+	/delete-property/ phy-handle;
+	/delete-property/ phy-connection-type;
+	managed = "in-band-status";
+	phys = <&serdes_2 2>;
+	sfp = <&c1_bb_sfp>;
+};
+
+/* sfp port 16 */
+&dpmac18 {
+	managed = "in-band-status";
+	phys = <&serdes_2 3>;
+	sfp = <&c2_ab_sfp>;
+};
+
+&esdhc0 {
+	pinctrl-0 = <&esdhc0_cd_wp_pins>, <&esdhc0_cmd_data30_clk_vsel_pins>;
+	pinctrl-names = "default";
+	/*
+	 * Disable 1.8V modes so that microsd state is same between
+	 * power-on-reset, u-boot and linux.
+	 * This avoids sporadic read errors after hard reset with some cards.
+	 */
+	no-1-8-v;
+	status = "okay";
+};
+
+&i2c2 {
+	expander0: gpio@20 {
+		compatible = "nxp,pca9555";
+		reg = <0x20>;
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+
+	expander1: gpio@21 {
+		compatible = "nxp,pca9555";
+		reg = <0x21>;
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+
+	expander2: gpio@24 {
+		compatible = "nxp,pca9555";
+		reg = <0x24>;
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+
+	expander3: gpio@25 {
+		compatible = "nxp,pca9555";
+		reg = <0x25>;
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+
+	/* Half twins configuration; take over c3 from the other twin side */
+	i2c-mux@73 {
+		compatible = "nxp,pca9547";
+		reg = <0x73>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		i2c-mux-idle-disconnect;
+
+		htwins_sfp_c3_at_i2c: i2c@3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		htwins_sfp_c3_ab_i2c: i2c@4 {
+			reg = <4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		htwins_sfp_c3_bt_i2c: i2c@5 {
+			reg = <5>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		htwins_sfp_c3_bb_i2c: i2c@6 {
+			reg = <6>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
+	i2c-mux@76 {
+		compatible = "nxp,pca9547";
+		reg = <0x76>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		i2c-mux-idle-disconnect;
+
+		twins_sfp_c1_at_i2c: i2c@1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c1_ab_i2c: i2c@2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c1_bt_i2c: i2c@3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c1_bb_i2c: i2c@4 {
+			reg = <4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c2_at_i2c: i2c@5 {
+			reg = <5>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c2_ab_i2c: i2c@6 {
+			reg = <6>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
+	i2c-mux@77 {
+		compatible = "nxp,pca9547";
+		reg = <0x77>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		i2c-mux-idle-disconnect;
+
+		twins_sfp_c2_bt_i2c: i2c@1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c2_bb_i2c: i2c@2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c3_at_i2c: i2c@3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c3_ab_i2c: i2c@4 {
+			reg = <4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c3_bt_i2c: i2c@5 {
+			reg = <5>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		twins_sfp_c3_bb_i2c: i2c@6 {
+			reg = <6>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
+
+&pcie5 {
+	status = "okay";
+};
+
+&pcs_mdio3 {
+	status = "okay";
+};
+
+&pcs_mdio4 {
+	status = "okay";
+};
+
+&pcs_mdio5 {
+	status = "okay";
+};
+
+&pcs_mdio6 {
+	status = "okay";
+};
+
+&pcs_mdio7 {
+	status = "okay";
+};
+
+&pcs_mdio8 {
+	status = "okay";
+};
+
+&pcs_mdio9 {
+	status = "okay";
+};
+
+&pcs_mdio10 {
+	status = "okay";
+};
+
+&pcs_mdio11 {
+	status = "okay";
+};
+
+&pcs_mdio12 {
+	status = "okay";
+};
+
+&pcs_mdio13 {
+	status = "okay";
+};
+
+&pcs_mdio14 {
+	status = "okay";
+};
+
+&pcs_mdio15 {
+	status = "okay";
+};
+
+&pcs_mdio16 {
+	status = "okay";
+};
+
+&pcs_mdio17 {
+	status = "okay";
+};
+
+&pcs_mdio18 {
+	status = "okay";
+};
+
+&rgmii_phy1 {
+	/*
+	 * COM has a phy at address 1 connected to SoC Ethernet Controller 1.
+	 * It competes for WRIOP MAC17, and no connector has been wired.
+	 */
+	status = "disabled";
+};
+
+&serdes_2 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&usb0 {
+	status = "okay";
+};
+
+&wriop_alert {
+	temperature = <100000>;
+};
+
+&wriop_crit {
+	temperature = <105000>;
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 479982948ee53..1d73abffa6b72 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -499,13 +499,13 @@ ddr-ctrl5-thermal {
 			thermal-sensors = <&tmu 1>;
 
 			trips {
-				ddr-cluster5-alert {
+				cluster5_alert: ddr-cluster5-alert {
 					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
 
-				ddr-cluster5-crit {
+				cluster5_crit: ddr-cluster5-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";
@@ -519,13 +519,13 @@ wriop-thermal {
 			thermal-sensors = <&tmu 2>;
 
 			trips {
-				wriop-alert {
+				wriop_alert: wriop-alert {
 					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
 
-				wriop-crit {
+				wriop_crit: wriop-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";
@@ -539,13 +539,13 @@ dce-thermal {
 			thermal-sensors = <&tmu 3>;
 
 			trips {
-				dce-qbman-alert {
+				dce_qbman_alert: dce-qbman-alert {
 					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
 
-				dce-qbman-crit {
+				dce_qbman_crit: dce-qbman-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";
@@ -559,13 +559,13 @@ ccn-thermal {
 			thermal-sensors = <&tmu 4>;
 
 			trips {
-				ccn-dpaa-alert {
+				ccn_dpaa_alert: ccn-dpaa-alert {
 					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
 
-				ccn-dpaa-crit {
+				ccn_dpaa_crit: ccn-dpaa-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";
@@ -579,13 +579,13 @@ cluster4-thermal {
 			thermal-sensors = <&tmu 5>;
 
 			trips {
-				clust4-hsio3-alert {
+				cluster4_alert: clust4-hsio3-alert {
 					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
 
-				clust4-hsio3-crit {
+				cluster4_crit: clust4-hsio3-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";
@@ -599,13 +599,13 @@ cluster2-3-thermal {
 			thermal-sensors = <&tmu 6>;
 
 			trips {
-				cluster2-3-alert {
+				cluster2_3_alert: cluster2-3-alert {
 					temperature = <85000>;
 					hysteresis = <2000>;
 					type = "passive";
 				};
 
-				cluster2-3-crit {
+				cluster2_3_crit: cluster2-3-crit {
 					temperature = <95000>;
 					hysteresis = <2000>;
 					type = "critical";

-- 
2.51.0

Re: [PATCH v7 9/9] arm64: dts: Add support for LX2160 Twins board in single configuration

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `gpio-mux` node for the fan tachometer multiplexer lacks an in-kernel consumer, which permanently locks the GPIOs and prevents the mux from being switched.
--

commit 3c28f80d13a11b4ba012fa933362f3d2ffeec63c
Author: Josua Mayer <josua@solid-run.com>

arm64: dts: Add support for LX2160 Twins board in single configuration

This commit adds device tree support for the SolidRun LX2160A Twins board
in a single CPU configuration. It adds hardware support for various
interfaces including SFP ports, OCP, USB, microSD, and power supplies.

> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
> new file mode 100644
> index 0000000000000..d16e273072754
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts

[ ... ]

> +	mux-controller {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		/*
> +		 * This gpio controlled mux can route the tacho signals of 6 PWM FAN connectors
> +		 * to the tacho inputs of both CEX-7 modules (twins).
> +		 *
> +		 * The first twin controls this mux and monitors four fan connectors, two intended
> +		 * for itself, and two for the OCP card.
> +		 *
> +		 * The second twin monitors only two fan connectors intended for itself.
> +		 *
> +		 * The table below maps selector GPIO states to monitored fan connector per twin:
> +		 *
> +		 * | SEL1 | SEL0 | Twin 1 | Twin 2 |
> +		 * | ---: | ---: | :------| ------ |
> +		 * |    0 |    0 | J10    |  J5024 |
> +		 * |    0 |    1 | J5016  |  J5024 |
> +		 * |    1 |    0 | J5026  |  J5025 |
> +		 * |    1 |    1 | J5013  |  J5025 |
> +		 */
> +		mux-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>, /* SEL0 */
> +			    <&expander0 15 GPIO_ACTIVE_HIGH>; /* SEL1 */
> +	};

[Severity: Medium]
Does this mux-controller lack an in-kernel consumer?

When the gpio-mux driver probes, it exclusively requests and locks these GPIOs.
However, there appears to be no consumer node in the device tree referencing
this multiplexer to actually switch it.

Since the Linux mux subsystem doesn't provide a userspace interface for
switching, and the GPIO subsystem denies userspace access to locked pins, does
this completely prevent both the kernel and userspace from switching the fan
tachometer multiplexer?

If so, doesn't this permanently lock the fan monitoring functionality in its
default state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524-lx2160-pci-v7-0-09370c23b952@solid-run.com?part=9

Re: [PATCH v7 9/9] arm64: dts: Add support for LX2160 Twins board in single configuration

[Josua Mayer]

Am 24.05.26 um 18:19 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The `gpio-mux` node for the fan tachometer multiplexer lacks an in-kernel consumer, which permanently locks the GPIOs and prevents the mux from being switched.
> --
>
> commit 3c28f80d13a11b4ba012fa933362f3d2ffeec63c
> Author: Josua Mayer <josua@solid-run.com>
>
> arm64: dts: Add support for LX2160 Twins board in single configuration
>
> This commit adds device tree support for the SolidRun LX2160A Twins board
> in a single CPU configuration. It adds hardware support for various
> interfaces including SFP ports, OCP, USB, microSD, and power supplies.
>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
>> new file mode 100644
>> index 0000000000000..d16e273072754
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
> [ ... ]
>
>> +	mux-controller {
>> +		compatible = "gpio-mux";
>> +		#mux-control-cells = <0>;
>> +		/*
>> +		 * This gpio controlled mux can route the tacho signals of 6 PWM FAN connectors
>> +		 * to the tacho inputs of both CEX-7 modules (twins).
>> +		 *
>> +		 * The first twin controls this mux and monitors four fan connectors, two intended
>> +		 * for itself, and two for the OCP card.
>> +		 *
>> +		 * The second twin monitors only two fan connectors intended for itself.
>> +		 *
>> +		 * The table below maps selector GPIO states to monitored fan connector per twin:
>> +		 *
>> +		 * | SEL1 | SEL0 | Twin 1 | Twin 2 |
>> +		 * | ---: | ---: | :------| ------ |
>> +		 * |    0 |    0 | J10    |  J5024 |
>> +		 * |    0 |    1 | J5016  |  J5024 |
>> +		 * |    1 |    0 | J5026  |  J5025 |
>> +		 * |    1 |    1 | J5013  |  J5025 |
>> +		 */
>> +		mux-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>, /* SEL0 */
>> +			    <&expander0 15 GPIO_ACTIVE_HIGH>; /* SEL1 */
>> +	};
> [Severity: Medium]
> Does this mux-controller lack an in-kernel consumer?
>
> When the gpio-mux driver probes, it exclusively requests and locks these GPIOs.
> However, there appears to be no consumer node in the device tree referencing
> this multiplexer to actually switch it.
>
> Since the Linux mux subsystem doesn't provide a userspace interface for
> switching, and the GPIO subsystem denies userspace access to locked pins, does
> this completely prevent both the kernel and userspace from switching the fan
> tachometer multiplexer?
>
> If so, doesn't this permanently lock the fan monitoring functionality in its
> default state?
>
As stated in previous version, the topology is too complex for hwmon
framework to utilize, so there is no in-kernel consumer.

The mux exists however and should be described.

Re: [PATCH v7 0/9] arm64: dts: lx2160a: cleanups, add new board, large pci bars

[Frank.Li]

From: Frank Li <Frank.Li@nxp.com>


On Sun, 24 May 2026 16:54:39 +0200, Josua Mayer wrote:
> This patch-set is made of 3 parts:
>
> 1. Extend lx2160 pci node ranges to support 16-bit, and large 64-bit
>    bars. LX2160A SoC has always supported this, and SolidRun carried it
>    in vendor fork for several years now.
>
> 2. Cleanup some status properties in LX2162A Clearfog dts.
>
> [...]

Applied, thanks!

[1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
      commit: fe4e8591406fbcaf718500436f01c4c6bf6aaeb9
[2/9] arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi
      commit: a95eda05c63a09dde4d2310132544597ba9fa92e
[3/9] arm64: dts: lx2162a-clearfog: cleanup superfluous status properties
      commit: 9daef7147485b82998f0edc5f5134d44ea98c9d1
[4/9] arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function
      commit: 71f99ff0b675c4679d358e2534a07822012d07de
[5/9] dt-bindings: arm: fsl: Add solidrun lx2160a twins board
      commit: 1c4e7398015e248ea80ed40ff02552c56b803e7b
[6/9] arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag
      commit: 81da028c8324bb490943117e1dfacff412847e13
[7/9] arm64: dts: lx2160a-clearfog-itx: move shared includes to dts
      commit: a2cb6757f56a4aa91a59403f167163fc6d57d016
[8/9] arm64: dts: lx2160a-cex7: add usb hub
      commit: 077ecb51d46b4a41d3c9085c92a1a04a566458c4
[9/9] arm64: dts: Add support for LX2160 Twins board in single configuration
      commit: b73fd8c02f95d4e8609ccecca1142ab35577aaf6


Fix typo and small turn commit message. Use term "PCIe"

Best regards,
--
Frank Li <Frank.Li@nxp.com>