* [PATCH v6 05/10] dt-bindings: arm: fsl: Add solidrun lx2160a twins board
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The SolidRun LX2160A Twins board supports two configurations, one with
with a sinle CEX-7 module, and one with two (dual).
The dual configuration was not yet tested.
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
^ permalink raw reply related
* [PATCH v6 10/10] arm64: dts: Add support for LX2160 Twins board in single configuration
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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 +
.../boot/dts/freescale/fsl-lx2160a-half-twins.dts | 826 +++++++++++++++++++++
2 files changed, 828 insertions(+)
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-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
new file mode 100644
index 0000000000000..ee1867f5b2b6b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
@@ -0,0 +1,826 @@
+// 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";
+};
+
+&wriop_alert {
+ temperature = <100000>;
+};
+
+&wriop_crit {
+ temperature = <105000>;
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v6 01/10] arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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
- drop IORESOURCE_BUSY flag
- add 64-bit region
See [1] and [2] for boot messages showing ranges before and after.
IORESOURCE_BUSY is dropped since it has no effect when specified in dts.
Setting IORESOURCE_MEM_64 flag on 64-bit region causes bootloader pci
patching logic and bar initialisation to fail [4], therefore it is
omitted.
For LX2160A Silicon revision 1, the 16GB 64-bit area is split into 4
pieces, because the layerscape pcie driver fails to program atu for
larger ranges [3].
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 +++++++++++-------
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 37 ++++++++++++++++++----
2 files changed, 49 insertions(+), 18 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..b5f52f3f84c7d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
@@ -14,8 +14,9 @@ &pcie1 {
0x80 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
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 = <0x42000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x88 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
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 = <0x42000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
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 = <0x42000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x98 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
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 = <0x42000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0xa0 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
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 = <0x42000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0xa8 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 479982948ee53..3f63fbf2485e5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -1193,7 +1193,12 @@ pcie1: pcie@3400000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x87 0x00000000 0x87 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x86 0x00000000 0x86 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x85 0x00000000 0x85 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x84 0x00000000 0x84 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
+
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1221,7 +1226,11 @@ pcie2: pcie@3500000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x8f 0x00000000 0x8f 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x8e 0x00000000 0x8e 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x8d 0x00000000 0x8d 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x8c 0x00000000 0x8c 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x88 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1249,7 +1258,11 @@ pcie3: pcie@3600000 {
apio-wins = <256>;
ppio-wins = <24>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x97 0x00000000 0x97 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x96 0x00000000 0x96 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x95 0x00000000 0x95 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x94 0x00000000 0x94 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1277,7 +1290,11 @@ pcie4: pcie@3700000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x9f 0x00000000 0x9f 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x9e 0x00000000 0x9e 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x9d 0x00000000 0x9d 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x9c 0x00000000 0x9c 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x98 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1305,7 +1322,11 @@ pcie5: pcie@3800000 {
apio-wins = <256>;
ppio-wins = <24>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0xa7 0x00000000 0xa7 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xa6 0x00000000 0xa6 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xa5 0x00000000 0xa5 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xa4 0x00000000 0xa4 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0xa0 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1333,7 +1354,11 @@ pcie6: pcie@3900000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0xaf 0x00000000 0xaf 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xae 0x00000000 0xae 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xad 0x00000000 0xad 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xac 0x00000000 0xac 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0xa8 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
--
2.51.0
^ permalink raw reply related
* [PATCH v6 08/10] arm64: dts: lx2160a: add labels to thermal trip-point nodes
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
LX2160A SoC dtsi defines rather conservative thermal trip points,
alert at 85°C and critical at 95°C.
This is okay for most boards, however the SoC maximum junction
temperature is 105°C in both commercial and industrial version.
Industrial grade boards need to change the thresholds to avoid premature
thermal shutdown in high-temeprature environments.
Add labels to all thermal trip point nodes, enabling board dts to
reference them and modify properties.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 3f63fbf2485e5..e2de7e596d2b6 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
^ permalink raw reply related
* [PATCH v6 09/10] arm64: dts: lx2160a-cex7: add labels to i2c buses behind mux
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The LX2160 CEX-7 module integrates in i2c bus multiplexer. Some of its
channel nodes have labels, others do not.
Add descriptive labels to the unlabeled channels, allowing other board
dts to reference them for example in aliases.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 8 ++++----
1 file changed, 4 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..ce63545abb6e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -58,7 +58,7 @@ i2c-mux@77 {
#size-cells = <0>;
reg = <0x77>;
- i2c@0 {
+ ddr_i2c: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
@@ -84,7 +84,7 @@ eeprom@57 {
};
};
- i2c@1 {
+ fan_i2c: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
@@ -95,7 +95,7 @@ fan-temperature-ctrlr@18 {
};
};
- i2c@2 {
+ power_i2c: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
@@ -106,7 +106,7 @@ regulator@5c {
};
};
- i2c@3 {
+ i2c_smb: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
--
2.51.0
^ permalink raw reply related
* [PATCH v6 07/10] arm64: dts: lx2160a-clearfog-itx: move shared includes to dts
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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
^ permalink raw reply related
* [PATCH v6 04/10] arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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
^ permalink raw reply related
* [PATCH v6 06/10] arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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
^ permalink raw reply related
* [PATCH v6 00/10] arm64: dts: lx2160a: cleanups, add new board, large pci bars
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, 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 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 (10):
arm64: dts: lx2160a: 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: add labels to thermal trip-point nodes
arm64: dts: lx2160a-cex7: add labels to i2c buses behind mux
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 | 12 +-
.../boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +
.../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 3 -
.../boot/dts/freescale/fsl-lx2160a-half-twins.dts | 826 +++++++++++++++++++++
.../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 | 61 +-
.../boot/dts/freescale/fsl-lx2162a-clearfog.dts | 37 +-
10 files changed, 913 insertions(+), 63 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20240118-lx2160-pci-4bdb196e58f3
Best regards,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH v6 03/10] arm64: dts: lx2162a-clearfog: cleanup superfluous status properties
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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 = <ðernet_phy3>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac12 {
phys = <&serdes_2 1>;
phy-handle = <ðernet_phy1>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac13 {
phys = <&serdes_2 6>;
phy-handle = <ðernet_phy6>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac14 {
phys = <&serdes_2 7>;
phy-handle = <ðernet_phy8>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac15 {
phys = <&serdes_2 4>;
phy-handle = <ðernet_phy4>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac16 {
phys = <&serdes_2 5>;
phy-handle = <ðernet_phy2>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac17 {
@@ -170,14 +163,12 @@ &dpmac17 {
phys = <&serdes_2 2>;
phy-handle = <ðernet_phy5>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac18 {
phys = <&serdes_2 3>;
phy-handle = <ðernet_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
^ permalink raw reply related
* [PATCH v6 02/10] arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
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
^ permalink raw reply related
* Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub
From: Catalin Marinas @ 2026-05-12 14:38 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, linux-arm-kernel, Greg KH, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Jonathan Cameron, Suzuki K Poulose
In-Reply-To: <20260427061615.905018-3-aneesh.kumar@kernel.org>
+ Suzuki again
On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> The SMCCC firmware driver now creates the `arm-smccc` platform device
> and also creates the CCA auxiliary devices once the RSI ABI is
> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
> helper redundant. Remove the arm-cca-dev platform device registration
> and let the SMCCC probe manage the RSI device.
>
> systemd match on platform:arm-cca-dev for confidential vm detection [1].
> Losing the platform device registration can break that. Keeping this
> removal in its own change makes it easy to revert if that regression
> blocks the rollout.
>
> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
I wouldn't merge this now given that systemd checks this file. Could we
have a symbolic link instead for some time until systemd eventually gets
updated (years?).
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support
From: Jonathan Cameron @ 2026-05-12 14:37 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, nuno.sa,
andy, dlechner, tychang, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, linux-realtek-soc, linux-iio, cy.huang,
stanley_chang, james.tai, Linus Walleij
In-Reply-To: <20260512033317.1602537-4-eleanor.lin@realtek.com>
On Tue, 12 May 2026 11:33:13 +0800
Yu-Chun Lin <eleanor.lin@realtek.com> wrote:
> Extend the reg_mask_xlate callback with an operation type parameter
> (gpio_regmap_operation) to allow drivers to return different
> register/mask combinations for different GPIO operations.
>
> Also add write-enable mechanism for hardware that requires setting a
> write-enable bit before modifying GPIO control registers.
>
> Consequently, update all existing drivers utilizing the gpio-regmap
> framework (across drivers/gpio, drivers/iio, and drivers/pinctrl)
> to accommodate the new reg_mask_xlate function signature.
What is the reasoning behind setting *mask = 0 for unsupported operations?
If it is a special value why not just return an error code to indicate
not supported? This seems to come from the assumption that you will want
to | that with masks for another operation.
I'm coming into this late but to me there look to be a bunch of undocumented
assumptions. Why do the operations have to share a register for example?
Perhaps an interface where you provide a single operation for write_enable
and whatever else and hence t here is only one 'reg' would work better?
>
> Suggested-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
> index deb9eebb58de..c76eef20e412 100644
> --- a/drivers/gpio/gpio-regmap.c
> +++ b/drivers/gpio/gpio-regmap.c
> @@ -38,9 +38,10 @@ struct gpio_regmap {
> struct regmap_irq_chip_data *irq_chip_data;
> #endif
>
> - int (*reg_mask_xlate)(struct gpio_regmap *gpio, unsigned int base,
> - unsigned int offset, unsigned int *reg,
> - unsigned int *mask);
> + int (*reg_mask_xlate)(struct gpio_regmap *gpio,
> + enum gpio_regmap_operation op,
> + unsigned int base, unsigned int offset,
> + unsigned int *reg, unsigned int *mask);
>
> void *driver_data;
> };
> @@ -54,6 +55,7 @@ static unsigned int gpio_regmap_addr(unsigned int addr)
> }
>
> static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> + enum gpio_regmap_operation op,
> unsigned int base, unsigned int offset,
> unsigned int *reg, unsigned int *mask)
> {
> @@ -61,7 +63,16 @@ static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> unsigned int stride = offset / gpio->ngpio_per_reg;
>
> *reg = base + stride * gpio->reg_stride;
> - *mask = BIT(line);
> +
> + switch (op) {
> + case GPIO_REGMAP_SET_WREN_OP:
> + case GPIO_REGMAP_SET_DIR_WREN_OP:
> + *mask = 0;
> + break;
> + default:
> + *mask = BIT(line);
> + break;
> + }
>
> return 0;
> }
> @@ -69,7 +80,7 @@ static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> static int gpio_regmap_get(struct gpio_chip *chip, unsigned int offset)
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> - unsigned int base, val, reg, mask;
> + unsigned int base, val, reg, mask, dir_mask;
> int ret;
>
> /* we might not have an output register if we are input only */
> @@ -78,10 +89,24 @@ static int gpio_regmap_get(struct gpio_chip *chip, unsigned int offset)
> else
> base = gpio_regmap_addr(gpio->reg_set_base);
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_GET_OP, base, offset, ®, &dir_mask);
> if (ret)
> return ret;
>
> + ret = regmap_read(gpio->regmap, reg, &val);
> + if (ret)
> + return ret;
> +
> + if (val & dir_mask) {
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_OUT, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> + } else {
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_IN, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> + }
> +
> /* ensure we don't spoil any register cache with pin input values */
> if (gpio->reg_dat_base == gpio->reg_set_base)
> ret = regmap_read_bypassed(gpio->regmap, reg, &val);
> @@ -98,10 +123,14 @@ static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> unsigned int base = gpio_regmap_addr(gpio->reg_set_base);
> - unsigned int reg, mask, mask_val;
> + unsigned int reg, mask, mask_val, wren_mask;
> int ret;
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, ®, &wren_mask);
> + if (ret)
> + return ret;
> +
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_OP, base, offset, ®, &mask);
> if (ret)
> return ret;
>
> @@ -112,9 +141,9 @@ static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
>
> /* ignore input values which shadow the old output value */
> if (gpio->reg_dat_base == gpio->reg_set_base)
> - ret = regmap_write_bits(gpio->regmap, reg, mask, mask_val);
> + ret = regmap_write_bits(gpio->regmap, reg, mask | wren_mask, mask_val | wren_mask);
> else
> - ret = regmap_update_bits(gpio->regmap, reg, mask, mask_val);
> + ret = regmap_update_bits(gpio->regmap, reg, mask | wren_mask, mask_val | wren_mask);
>
> return ret;
> }
> @@ -123,7 +152,7 @@ static int gpio_regmap_set_with_clear(struct gpio_chip *chip,
> unsigned int offset, int val)
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> - unsigned int base, reg, mask;
> + unsigned int base, reg, mask, wren_mask;
> int ret;
>
> if (val)
> @@ -131,11 +160,15 @@ static int gpio_regmap_set_with_clear(struct gpio_chip *chip,
> else
> base = gpio_regmap_addr(gpio->reg_clr_base);
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, ®, &wren_mask);
> if (ret)
> return ret;
>
> - return regmap_write(gpio->regmap, reg, mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WITH_CLEAR_OP, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> +
> + return regmap_write(gpio->regmap, reg, mask | wren_mask);
> }
>
> static int gpio_regmap_get_direction(struct gpio_chip *chip,
> @@ -167,7 +200,7 @@ static int gpio_regmap_get_direction(struct gpio_chip *chip,
> return -ENOTSUPP;
> }
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_GET_DIR_OP, base, offset, ®, &mask);
> if (ret)
> return ret;
>
> @@ -185,7 +218,7 @@ static int gpio_regmap_set_direction(struct gpio_chip *chip,
> unsigned int offset, bool output)
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> - unsigned int base, val, reg, mask;
> + unsigned int base, val, reg, mask, wren_mask;
> int invert, ret;
>
> if (gpio->reg_dir_out_base) {
> @@ -198,7 +231,12 @@ static int gpio_regmap_set_direction(struct gpio_chip *chip,
> return -ENOTSUPP;
> }
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_OP, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> +
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP, base, offset, ®,
> + &wren_mask);
What constrains these two to provide the same value back for reg?
To me it seems like the write enable might well be in a different register.
> if (ret)
> return ret;
>
> @@ -207,7 +245,7 @@ static int gpio_regmap_set_direction(struct gpio_chip *chip,
> else
> val = output ? mask : 0;
>
> - return regmap_update_bits(gpio->regmap, reg, mask, val);
> + return regmap_update_bits(gpio->regmap, reg, mask | wren_mask, val | wren_mask);
> }
>
> static int gpio_regmap_direction_input(struct gpio_chip *chip,
^ permalink raw reply
* Re: [PATCH v4 1/2] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Catalin Marinas @ 2026-05-12 14:36 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, linux-arm-kernel, Greg KH, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Suzuki K Poulose
In-Reply-To: <20260427061615.905018-2-aneesh.kumar@kernel.org>
+ Suzuki
On Mon, Apr 27, 2026 at 11:46:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..2d2d363aaaee 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -10,7 +10,7 @@
> #include <linux/jump_label.h>
> #include <asm/rsi_cmds.h>
>
> -#define RSI_PDEV_NAME "arm-cca-dev"
> +#define RSI_DEV_NAME "arm-rsi-dev"
[...]
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd..fc9b44b7c687 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -12,6 +12,8 @@
> #include <linux/platform_device.h>
> #include <asm/archrandom.h>
>
> +#include "rmm.h"
> +
> static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
>
> @@ -85,6 +87,18 @@ static int __init smccc_devices_init(void)
> {
> struct platform_device *pdev;
>
> + pdev = platform_device_register_simple("arm-smccc",
> + PLATFORM_DEVID_NONE, NULL, 0);
> + if (IS_ERR(pdev)) {
> + pr_err("arm-smccc: could not register device: %ld\n", PTR_ERR(pdev));
> + } else {
> + /*
> + * Register the RMI and RSI devices only when firmware exposes
> + * the required SMCCC function IDs at a supported revision.
> + */
> + register_rsi_device(pdev);
> + }
So as per the cover letter, instead of "arm-cca-dev" as a platform
device, we get "arm-smccc" as a platform device with an auxiliary
"arm-rsi-dev" child device. This does not get rid of the platform
device, it just creates a synthetic platform device to represent the
SMCCC firmware interface.
Looking at the earlier discussion, I think this is what Greg/Jason were
suggesting, except that we do not currently have an SMCCC platform
device:
https://lore.kernel.org/all/2025101534-frosty-shank-00b1@gregkh/
If we go this route, shouldn't the platform device above be created only
if !SMCCC_CONDUIT_NONE?
"smccc_trng" would also fit this model (together with the driver),
assuming we don't break any user-space (searching the Debian codebase
did not find any use).
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver
From: Roman Vivchar @ 2026-05-12 14:34 UTC (permalink / raw)
To: Jonathan Cameron, Andy Shevchenko
Cc: David Lechner, Nuno Sá, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Srinivas Kandagatla,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512142932.5c6801d1@jic23-huawei>
On Tuesday, May 12th, 2026 at 4:29 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Tue, 12 May 2026 08:18:19 +0300
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
...
> > +#define VOLTAGE_FULL_RANGE 1800
> Probably better to have this inline - however if you do keep it
> prefix t he define VOLTAGE_FULL_RANGE sounds too generic!
>
> > +#define AUXADC_PRECISE 32768
> I'd put that inline. Little benefit it in having it up here...
There was a mention about magic values in the v1 for the thermal patch [1].
Andy, would it be better to use an inline style or a #define here?
If the former, I'll rename the first constant to something like
AUXADC_VOLTAGE_FULL_RANGE.
[1]: https://lore.kernel.org/linux-mediatek/afmnUG8dG0N0HpV6@ashevche-desk.local/
Best regards,
Roman
^ permalink raw reply
* Re: [PATCH v3 3/3] iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
From: Salih Erim @ 2026-05-12 14:34 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414224245.8493-4-guilherme.bozi@usp.br>
Hi,
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> Replace multiple open-coded switch statements that map between
> scan_index, alarm bits, and register offsets with a centralized
> table-driven approach.
>
> Introduce a struct-based alarm_map to describe the relationship
> between scan indices and alarm offsets, and add a helper to
> translate scan_index to event IDs. This removes duplicated logic
> across ams_get_alarm_offset(), ams_event_to_channel(), and
> ams_get_alarm_mask().
>
> The new approach improves maintainability, reduces code size,
> and makes it easier to extend or modify alarm mappings in the
> future, while preserving existing behavior.
>
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> ---
> drivers/iio/adc/xilinx-ams.c | 161 +++++++++++++----------------------
> 1 file changed, 58 insertions(+), 103 deletions(-)
Two issues:
1) Same tabs-vs-spaces indentation problem as patches 1 and 2.
2) In ams_event_to_channel():
> + if (event < 0 || event >= ARRAY_SIZE(alarm_map))
> + return NULL;
The 'event' parameter is u32, so 'event < 0' is always false.
Either drop the < 0 check or change the parameter type to int
if you intend to handle negative values.
Salih
^ permalink raw reply
* [PATCH v4 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
From: Maxime Ripard @ 2026-05-12 13:06 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260512-drm-mode-config-init-v4-0-591dfdcc1bf9@kernel.org>
__drm_atomic_helper_crtc_state_reset() is used to initialize a newly
allocated drm_crtc_state, and is being typically called by the
drm_crtc_funcs.reset implementation.
Since we want to consolidate DRM objects state allocation around the
atomic_create_state callback that will only allocate and initialize a
new drm_crtc_state instance, we will need to call
__drm_atomic_helper_crtc_state_reset() from both the reset and
atomic_create hooks.
To avoid any confusion, we can thus rename
__drm_atomic_helper_crtc_state_reset() to
__drm_atomic_helper_crtc_state_init().
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
include/drm/drm_atomic_state_helper.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index ab171bfe6e86..b277f92f4532 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -61,25 +61,25 @@
* For other drivers the building blocks are split out, see the documentation
* for these functions.
*/
/**
- * __drm_atomic_helper_crtc_state_reset - reset the CRTC state
+ * __drm_atomic_helper_crtc_state_init - Initialize the CRTC state
* @crtc_state: atomic CRTC state, must not be NULL
* @crtc: CRTC object, must not be NULL
*
* Initializes the newly allocated @crtc_state with default
* values. This is useful for drivers that subclass the CRTC state.
*/
void
-__drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
- struct drm_crtc *crtc)
+__drm_atomic_helper_crtc_state_init(struct drm_crtc_state *crtc_state,
+ struct drm_crtc *crtc)
{
crtc_state->crtc = crtc;
crtc_state->background_color = DRM_ARGB64_PREP(0xffff, 0, 0, 0);
}
-EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
+EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_init);
/**
* __drm_atomic_helper_crtc_reset - reset state on CRTC
* @crtc: drm CRTC
* @crtc_state: CRTC state to assign
@@ -94,11 +94,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
void
__drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
if (crtc_state)
- __drm_atomic_helper_crtc_state_reset(crtc_state, crtc);
+ __drm_atomic_helper_crtc_state_init(crtc_state, crtc);
if (drm_dev_has_vblank(crtc->dev))
drm_crtc_vblank_reset(crtc);
crtc->state = crtc_state;
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index 03de219f7a64..7486f2dc60ef 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -179,11 +179,11 @@ struct intel_crtc_state *intel_crtc_state_alloc(struct intel_crtc *crtc)
void intel_crtc_state_reset(struct intel_crtc_state *crtc_state,
struct intel_crtc *crtc)
{
memset(crtc_state, 0, sizeof(*crtc_state));
- __drm_atomic_helper_crtc_state_reset(&crtc_state->uapi, &crtc->base);
+ __drm_atomic_helper_crtc_state_init(&crtc_state->uapi, &crtc->base);
crtc_state->cpu_transcoder = INVALID_TRANSCODER;
crtc_state->master_transcoder = INVALID_TRANSCODER;
crtc_state->hsw_workaround_pipe = INVALID_PIPE;
crtc_state->scaler_state.scaler_id = -1;
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 8d1ef268fdef..0bb72453464a 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -38,11 +38,11 @@ struct drm_connector_state;
struct drm_private_obj;
struct drm_private_state;
struct drm_modeset_acquire_ctx;
struct drm_device;
-void __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *state,
+void __drm_atomic_helper_crtc_state_init(struct drm_crtc_state *state,
struct drm_crtc *crtc);
void __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
From: Frank Li @ 2026-05-12 14:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <f04fadf2-8d73-435b-b713-9d07e48e80ae@lunn.ch>
On Tue, May 12, 2026 at 12:15:08AM +0200, Andrew Lunn wrote:
> On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> > According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> > is connected to the station management entity via the mechanical interface
> > defined in 22.6 shall always respond to transactions addressed to PHY
> > Address zero <00000>.
>
> Did you read 22.6? I've not seen a mechanical interface as defined in
> 22.6 for at least 20 years, maybe 30 years.
>
> That cause does not apply in this context.
Thanks, I missed understand it. This board is still alive, let me double
check it.
Frank
>
> > - ethphy: ethernet-phy {
> > + ethphy: ethernet-phy@0 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
>
> This could very well break this board. Without a reg value, the core
> will find the first PHY on the bus, at whatever address it is at. If
> you hard code 0, the PHY must be at 0, otherwise it will not be found.
>
> Andrew
^ permalink raw reply
* Re: [PATCH v3 2/3] iio: adc: xilinx-ams: use guard(mutex) for automatic locking
From: Salih Erim @ 2026-05-12 14:25 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Andy Shevchenko
In-Reply-To: <20260414224245.8493-3-guilherme.bozi@usp.br>
Hi,
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> Replace open-coded mutex_lock()/mutex_unlock() pairs with
> guard(mutex) to simplify locking and ensure proper unlock on
> all control flow paths.
>
> This removes explicit unlock handling, reduces boilerplate,
> and avoids potential mistakes in error paths while keeping
> the behavior unchanged.
>
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> ---
> drivers/iio/adc/xilinx-ams.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
Same indentation issue -- spaces instead of tabs on all new lines.
Salih
^ permalink raw reply
* Re: [PATCH v3 1/3] iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling
From: Salih Erim @ 2026-05-12 14:22 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414224245.8493-2-guilherme.bozi@usp.br>
Hi Guilherme,
Replies are inline.
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> ams_event_to_channel() may return a pointer past the end of
> dev->channels when no matching scan_index is found. This can lead
> to invalid memory access in ams_handle_event().
>
> Add a bounds check in ams_event_to_channel() and return NULL when
> no channel is found. Also guard the caller to safely handle this
> case.
>
> Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> ---
> drivers/iio/adc/xilinx-ams.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
> index 124470c92529..6191cd1b29a5 100644
> --- a/drivers/iio/adc/xilinx-ams.c
> +++ b/drivers/iio/adc/xilinx-ams.c
> @@ -871,6 +871,9 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
> if (dev->channels[i].scan_index == scan_index)
> break;
>
> + if (i == dev->num_channels)
> + return NULL;
> +
The added lines use spaces for indentation instead of tabs.
Salih
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: Michal Simek @ 2026-05-12 14:21 UTC (permalink / raw)
To: David Lechner, Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Lars-Peter Clausen, linux-iio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <db7fc677-56bb-4421-969d-6116a0a57d77@baylibre.com>
On 5/12/26 16:16, David Lechner wrote:
> On 5/12/26 9:10 AM, Michal Simek wrote:
>>
>>
>> On 5/12/26 15:58, David Lechner wrote:
>>> On 5/12/26 7:14 AM, Rob Herring wrote:
>>>> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>>>>
>>>>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>>>>> On Sun, 10 May 2026 08:01:36 -0400
>>>>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>>>>
>>>>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>>>>> validation with dt-schema.
>>>>>>>
>>>>>>> The new binding covers the same hardware and compatible strings:
>>>>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>>>>
>>>>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>>>>> Hi Pramod,
>>>>>>
>>>>>> Something went wrong with your sending of v3. I have two versions sent
>>>>>> half a day apart and no idea how they are related.
>>>>>>
>>>>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>>>>> getting a v4 and wait for that.
>>>>>>
>>>>>> Jonathan
>>>>>
>>>>> I think Rob will have to fix the bot to make an exception for the
>>>>> legacy bindings. This should have been called out in the commit message
>>>>> as requested in a previous revision.
>>>>
>>>> The bot is not the problem. It just runs validation. The schemas will
>>>> have to either drop this check (comma's in nodenames) or exclude just
>>>> this property.
>>>>
>>>>
>>>> Rob
>>>
>>> Even though this is an existing text-based schema that has been around
>>> for 12 years with this name already? Changing it could be a breaking
>>> change to existing users. Although there aren't any in any .dts in the
>>> kernel source.
>>
>> Zynq has it described.
>> arch/arm/boot/dts/xilinx/zynq-7000.dtsi:111: compatible = "xlnx,zynq-xadc-1.00.a";
>>
>> And make no sense to describe programmable logic which are that other two.
>>
>> Thanks,
>> Michal
>
> The issue is with the xlnx,channels property name. Searching only shows
> this in the driver and in the examples in the bindings .txt file.
Because it depends on HW design configuration. Different configuration have
different channels exposed. We are using device tree generator which take
current design configuration and describe them. zynq-7000.dtsi is generic for
all boards. I can't remember all details but I wouldn't be surprise if no
channel is exported on minimal/default designs which are described.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Salih Erim @ 2026-05-12 14:18 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
Hi Guilherme,
Thanks for working on this. The refactoring approach looks good overall,
but all three patches have indentation issues and patch 3 has one
semantic issue. Please see my comments on each patch.
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> This series addresses significant code duplication in alarm handling
> logic across the Xilinx AMS IIO driver.
>
> To address this, the series introduces a centralized table-driven
> mapping (alarm_map) that replaces multiple switch statements spread
> across the driver.
>
> This improves:
> - maintainability (single source of truth for mappings)
> - readability (removes repeated switch logic)
> - extensibility (new alarms require only table updates)
>
> No functional changes are intended.
>
> Series overview:
> - Patch 1: fix out-of-bounds channel lookup
> - Patch 2: convert mutex handling to guard(mutex)
> - Patch 3: introduce table-driven alarm mapping
>
> v1 -> v2:
> - Fixed Fixes tag format
> - Replaced AMS_ALARM_INVALID with AMS_ALARM_NONE
> - Changed alarm_map base_offset type
>
> v2 -> v3:
> - Replace 'i >= num_channels' with 'i == num_channels'
> - Add missing trailing comma in alarm_map array initializer
>
> Guilherme Ivo Bozi (3):
> iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event
> handling
> iio: adc: xilinx-ams: use guard(mutex) for automatic locking
> iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
>
> drivers/iio/adc/xilinx-ams.c | 190 +++++++++++++----------------------
> 1 file changed, 71 insertions(+), 119 deletions(-)
>
> --
> 2.47.3
>
Salih
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: David Lechner @ 2026-05-12 14:16 UTC (permalink / raw)
To: Michal Simek, Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Lars-Peter Clausen, linux-iio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cc26edcf-3218-4294-a522-ffafdaf41070@amd.com>
On 5/12/26 9:10 AM, Michal Simek wrote:
>
>
> On 5/12/26 15:58, David Lechner wrote:
>> On 5/12/26 7:14 AM, Rob Herring wrote:
>>> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>>>
>>>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>>>> On Sun, 10 May 2026 08:01:36 -0400
>>>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>>>
>>>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>>>> validation with dt-schema.
>>>>>>
>>>>>> The new binding covers the same hardware and compatible strings:
>>>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>>>
>>>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>>>> Hi Pramod,
>>>>>
>>>>> Something went wrong with your sending of v3. I have two versions sent
>>>>> half a day apart and no idea how they are related.
>>>>>
>>>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>>>> getting a v4 and wait for that.
>>>>>
>>>>> Jonathan
>>>>
>>>> I think Rob will have to fix the bot to make an exception for the
>>>> legacy bindings. This should have been called out in the commit message
>>>> as requested in a previous revision.
>>>
>>> The bot is not the problem. It just runs validation. The schemas will
>>> have to either drop this check (comma's in nodenames) or exclude just
>>> this property.
>>>
>>>
>>> Rob
>>
>> Even though this is an existing text-based schema that has been around
>> for 12 years with this name already? Changing it could be a breaking
>> change to existing users. Although there aren't any in any .dts in the
>> kernel source.
>
> Zynq has it described.
> arch/arm/boot/dts/xilinx/zynq-7000.dtsi:111: compatible = "xlnx,zynq-xadc-1.00.a";
>
> And make no sense to describe programmable logic which are that other two.
>
> Thanks,
> Michal
The issue is with the xlnx,channels property name. Searching only shows
this in the driver and in the examples in the bindings .txt file.
^ permalink raw reply
* Re: [PATCH v5 16/29] media: rockchip: rga: split flip and rotate into separate function
From: Nicolas Dufresne @ 2026-05-12 14:15 UTC (permalink / raw)
To: Sven Püschel, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <1f447423-8c63-4545-a4f7-d8d5ef821255@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 7379 bytes --]
Le mardi 12 mai 2026 à 16:08 +0200, Sven Püschel a écrit :
> Hi Nicolas,
>
> On 5/9/26 12:11 AM, Nicolas Dufresne wrote:
> > Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
> > > Split the flip and rotate command configuration into a separate
> > > function in preparation of filling the command stream at streamon.
> > > As the userspace can change the flipping and rotation controls while
> > > streaming, we have to update them with each new frame to prevent the
> > > user being unable to change them while streaming.
> > >
> > > Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
> > For code point of view, everything seems fine, but the commit message leave me a
> > bit wondering. Any rotation that isn't 180 degree will cause the width and
> > height to be reversed, and a new stride is needed to present the buffer
> > correctly. Meaning the capture format can be affected by this change.
>
> Sorry for missing to properly communicate my intention with this patch.
>
> I've stumbled over the RGA pulling a spin lock on the controls, when
> starting the next job [1]. This made me realize that the driver allows
> changing the controls while streaming, which my change to move the
> command buffer setup to streamon breaks (as a potential rotation isn't
> updated until the next streamon).
>
> This commit is the result of trying to not break the old behavior by
> moving the relevant code parts to be run on every frame instead of being
> only run at streamon. I didn't think about the 90 degree rotation
> problems, which are also present in the current RGA state.
>
> sashiko.dev also pointed out that my simple code move didn't work for
> the mirroring case [2], as the relevant command buffer is ore'd with the
> mirroring flags. Also I've noticed that the rotation mode affects the
> scaling factor. To avoid these footguns, I've got the idea to set a flag
> to raise when the controls change. Then I can fully re-initialize the
> command buffer on the next frame and fully avoid these kind of problems.
Thanks for the update, thanks for looking into that.
>
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/rockchip/rga/rga.c?id=50897c955902c93ae71c38698abb910525ebdc89#n41
>
> [2]
> https://sashiko.dev/#/patchset/20260428-spu-rga3-v5-0-eb7f5d019d86%40pengutronix.de?part=16
>
> >
> > To stick with the spec, the capture format needs to be updated, and it needs to
> > happen in a way user can be able to read it back for the correct frame if
> > userspace make use of the queues. I see 3 options, let me know what you think,
> > or what is later implemented if you already thought about that.
> >
> > 1. Synchronously update the capture format width/height, document in the
> > respective control this behaviour, leaving to userspace to remember which frames
> > the change will apply to.
> >
> > This works nicely for this type of HW, but would be a bit complicated for a
> > deinterlacer, since the buffering might be HW specific. It also make usage of
> > queues harder, less independent.
> >
> > 2. Force a drain/stop/start for any 90 degree rotation
> >
> > This might impose a longer idle time for the converter core, and is kind of
> > opposite of your commit message. But requires no spec work.
> >
> > 3. Emit SRC_CH, implement the drain procedure typical to decoder resolution
> > change.
> >
> > Typically it means userspace can keep buffering on the OUTPUT queue, and once
> > the LAST buffer is met, it can simply read the new format (and new stride, since
> > due to alignment, this might be hardware specific) and toggle streamoff/on only
> > on capture queue to reactivate the processing.
> >
> > The 3. is more complex for the driver, but its a proven race-free method for
> > decoders already. 2 would be statusquo to get this series in, and we could post-
> > poned more advance work for seamless 90degree rorations. 1., I don't really like
> > that solution, it not quite generic enough.
>
> I'll go with option 2 for now to keep it simple and improve the status
> quo a bit.
Works for me.
Nicolas
>
> Sincerely
> Sven
>
> > feedback welcome,
> > Nicolas
> >
> > > ---
> > > drivers/media/platform/rockchip/rga/rga-hw.c | 57 +++++++++++++++++-----------
> > > 1 file changed, 34 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
> > > index dac3cb6aa17d3..6c1956b04f6ba 100644
> > > --- a/drivers/media/platform/rockchip/rga/rga-hw.c
> > > +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
> > > @@ -156,7 +156,38 @@ static void rga_cmd_set_dst_addr(struct rga_ctx *ctx, dma_addr_t dma_addr)
> > > dest[reg >> 2] |= 0x7 << 8;
> > > }
> > >
> > > -static void rga_cmd_set_trans_info(struct rga_ctx *ctx)
> > > +static void rga_cmd_set_flip_rotate_info(struct rga_ctx *ctx)
> > > +{
> > > + u32 *dest = ctx->cmdbuf_virt;
> > > + union rga_src_info src_info;
> > > +
> > > + src_info.val = dest[(RGA_SRC_INFO - RGA_MODE_BASE_REG) >> 2];
> > > +
> > > + if (ctx->vflip)
> > > + src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_X;
> > > +
> > > + if (ctx->hflip)
> > > + src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_Y;
> > > +
> > > + switch (ctx->rotate) {
> > > + case 90:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_90_DEGREE;
> > > + break;
> > > + case 180:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_180_DEGREE;
> > > + break;
> > > + case 270:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_270_DEGREE;
> > > + break;
> > > + default:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_0_DEGREE;
> > > + break;
> > > + }
> > > +
> > > + dest[(RGA_SRC_INFO - RGA_MODE_BASE_REG) >> 2] = src_info.val;
> > > +}
> > > +
> > > +static void rga_cmd_set_format_scale_info(struct rga_ctx *ctx)
> > > {
> > > struct rockchip_rga *rga = ctx->rga;
> > > u32 *dest = ctx->cmdbuf_virt;
> > > @@ -219,27 +250,6 @@ static void rga_cmd_set_trans_info(struct rga_ctx *ctx)
> > > }
> > > }
> > >
> > > - if (ctx->vflip)
> > > - src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_X;
> > > -
> > > - if (ctx->hflip)
> > > - src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_Y;
> > > -
> > > - switch (ctx->rotate) {
> > > - case 90:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_90_DEGREE;
> > > - break;
> > > - case 180:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_180_DEGREE;
> > > - break;
> > > - case 270:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_270_DEGREE;
> > > - break;
> > > - default:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_0_DEGREE;
> > > - break;
> > > - }
> > > -
> > > /*
> > > * Calculate the up/down scaling mode/factor.
> > > *
> > > @@ -431,7 +441,8 @@ static void rga_cmd_set(struct rga_ctx *ctx,
> > >
> > > rga_cmd_set_src_info(ctx, &src->offset);
> > > rga_cmd_set_dst_info(ctx, &dst->offset);
> > > - rga_cmd_set_trans_info(ctx);
> > > + rga_cmd_set_format_scale_info(ctx);
> > > + rga_cmd_set_flip_rotate_info(ctx);
> > >
> > > rga_write(rga, RGA_CMD_BASE, ctx->cmdbuf_phy);
> > >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 06/29] media: rockchip: rga: fix too small buffer size
From: Sven Püschel @ 2026-05-12 14:14 UTC (permalink / raw)
To: Nicolas Dufresne, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <7cf0950e51e4917a0b4d565f71b1e8f2a41e4bbe.camel@ndufresne.ca>
Hi Nicolas,
On 5/8/26 11:11 PM, Nicolas Dufresne wrote:
> Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
>> Fix the command buffer size being only a quarter of the actual size.
>> The RGA_CMDBUF_SIZE macro was potentially intended to specify the length
>> of the cmdbuf u32 array pointer. But as it's used to specify the size of
>> the allocation, which is counted in bytes. Therefore adjust the macro
>> size to bytes as it better matches the variable name and adjust it's
>> users accordingly.
>>
>> As the command buffer is relatively small, it probably didn't caused
>> an issue due to being smaller than a single page.
>>
>> Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
>> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
>
>> ---
>> drivers/media/platform/rockchip/rga/rga-hw.c | 2 +-
>> drivers/media/platform/rockchip/rga/rga-hw.h | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
>> index 43ed742a16492..d1618bb247501 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.c
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
>> @@ -414,7 +414,7 @@ static void rga_cmd_set(struct rga_ctx *ctx,
>> {
>> struct rockchip_rga *rga = ctx->rga;
>>
>> - memset(rga->cmdbuf_virt, 0, RGA_CMDBUF_SIZE * 4);
>> + memset(rga->cmdbuf_virt, 0, RGA_CMDBUF_SIZE);
> So we had a buffer overrun ?
From my point of view, yes [1]:
/* Create CMD buffer */
rga->cmdbuf_virt = dma_alloc_attrs(rga->dev, RGA_CMDBUF_SIZE,
&rga->cmdbuf_phy, GFP_KERNEL,
DMA_ATTR_WRITE_COMBINE);
Given that 0x20 * 4 is smaller than a page, it probably didn't caused an
issue as we didn't write out of the one page allocated.
Btw.: I've noticed it while reading a bit over the comments from
sashiko.dev [2]. I'll also add this link for clarity to the comment in
my next series (seems to be the common way of referring to sashiko.dev).
Sincerely
Sven
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/rockchip/rga/rga.c?id=50897c955902c93ae71c38698abb910525ebdc89#n880
[2]
https://sashiko.dev/#/patchset/20260325-spu-rga3-v4-0-e90ec1c61354%40pengutronix.de?part=10
>
> Nicolas
>
>>
>> rga_cmd_set_src_addr(ctx, src->dma_desc_pa);
>> /*
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.h b/drivers/media/platform/rockchip/rga/rga-hw.h
>> index cc6bd7f5b0300..2b8537a5fd0d7 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.h
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.h
>> @@ -6,7 +6,7 @@
>> #ifndef __RGA_HW_H__
>> #define __RGA_HW_H__
>>
>> -#define RGA_CMDBUF_SIZE 0x20
>> +#define RGA_CMDBUF_SIZE 0x80
>>
>> /* Hardware limits */
>> #define MAX_WIDTH 8192
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox