Add support for Variscite VAR-SOM-MX8QM and Symphony board

PATCH In review Stefano Radaelli 4 participants 9 messages Jun 30 – Jul 13

Subsystems (2)

Device tree bindings Arm i.MX and Layerscape

lore

Share & tools

lore

Stefano Radaelli

author

2026-06-30 09:47 UTC #0 lore raw

cover Add support for Variscite VAR-SOM-MX8QM and Symphony board

This patch series adds support for the Variscite VAR-SOM-MX8 QuadMax system on module and the Symphony carrier board.

The series includes:
- SOM device tree with on-module peripherals
- Symphony carrier board device tree with board-specific features

The implementation follows the standard SOM + carrier board pattern where the SOM dtsi contains only peripherals mounted on the module, while carrier-specific interfaces are enabled in the board dts.

Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax
arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx8qm-var-som-symphony.dts | 488 ++++++++++++++++
 .../boot/dts/freescale/imx8qm-var-som.dtsi    | 529 ++++++++++++++++++
 4 files changed, 1024 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi

base-commit: 6d1a5ede11552f559ac02b31af03bfaa67f1e91f

Signature · 1 line

2.47.3

Stefano Radaelli

author

2026-06-30 09:47 UTC #1 lore raw

PATCH 1/3 dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards

From: Stefano Radaelli <[email protected]>

Add DT compatible strings for Variscite VAR-SOM-MX8 QuadMax SoM and Variscite Symphony development carrier Board.

Signed-off-by Stefano Radaelli <[email protected]>

---
 Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

Documentation/devicetree/bindings/arm/fsl.yaml +6 -0

index 86876311ec59..242a58eeb314 100644
@@ -1369,6 +1369,12 @@ properties:
               - fsl,imx8qm-mek-revd      # i.MX8QM MEK Rev D Board
           - const: fsl,imx8qm
 
+      - description: i.MX8QM Variscite VAR-SOM-MX8 based Boards
+        items:
+          - const: variscite,var-som-imx8qm-symphony
+          - const: variscite,var-som-imx8qm
+          - const: fsl,imx8qm
+
       - description: i.MX8QM Boards with Toradex Apalis iMX8 Modules
         items:
           - enum:

Signature · 1 line

2.47.3

Krzysztof Kozlowski

Acked-by on v1 1/3

2026-07-01 07:30 UTC #2 lore raw

Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards

Quoted 9 lines · Stefano Radaelli

From: Stefano Radaelli <[email protected]>
Add DT compatible strings for Variscite VAR-SOM-MX8 QuadMax SoM and Variscite Symphony development carrier Board.
Signed-off-by Stefano Radaelli <[email protected]>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

Acked-by Krzysztof Kozlowski <[email protected]>

Best regards,
Krzysztof

Stefano Radaelli

author

2026-06-30 09:47 UTC #3 lore raw

PATCH 2/3 arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

In reply to Stefano Radaelli

From: Stefano Radaelli <[email protected]>

Add device tree support for the Variscite VAR-SOM-MX8 QuadMax system on module.
This SOM is designed to be used with various carrier boards.

The module includes:
- NXP i.MX8 QuadMax MPU processor
- Up to 8GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth

Only SOM-specific peripherals are enabled by default. Carrier board specific interfaces are left disabled to be enabled in the respective carrier board device trees.

Link https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/

Signed-off-by Stefano Radaelli <[email protected]>

---
 .../boot/dts/freescale/imx8qm-var-som.dtsi    | 529 ++++++++++++++++++
 1 file changed, 529 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +529 -0

new file mode 100644
index 000000000000..2ffc32ddbf51
@@ -0,0 +1,529 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite VAR-SOM-MX8
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include "imx8qm.dtsi"
+
+/ {
+	model = "Variscite i.MX8QM VAR-SOM-MX8 Module";
+	compatible = "variscite,var-som-imx8qm", "fsl,imx8qm";
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x40000000>;
+	};
+
+	reg_audio_supply: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "wm8904-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_phy_vddio: regulator-phy-vddio {
+		compatible = "regulator-fixed";
+		regulator-name = "vddio-1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		vdev0vring0: memory@90000000 {
+			reg = <0 0x90000000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: memory@90008000 {
+			reg = <0 0x90008000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: memory@90010000 {
+			reg = <0 0x90010000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: memory@90018000 {
+			reg = <0 0x90018000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table0: memory@900ff000 {
+			reg = <0 0x900ff000 0 0x1000>;
+			no-map;
+		};
+
+		vdev2vring0: memory@90100000 {
+			reg = <0 0x90100000 0 0x8000>;
+			no-map;
+		};
+
+		vdev2vring1: memory@90108000 {
+			reg = <0 0x90108000 0 0x8000>;
+			no-map;
+		};
+
+		vdev3vring0: memory@90110000 {
+			reg = <0 0x90110000 0 0x8000>;
+			no-map;
+		};
+
+		vdev3vring1: memory@90118000 {
+			reg = <0 0x90118000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table1: memory@901ff000 {
+			reg = <0 0x901ff000 0 0x1000>;
+			no-map;
+		};
+
+		vdevbuffer: memory@90400000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x90400000 0 0x100000>;
+			no-map;
+		};
+
+		dsp_reserved: memory@92400000 {
+			reg = <0 0x92400000 0 0x1000000>;
+			no-map;
+		};
+
+		dsp_vdev0vring0: memory@942f0000 {
+			reg = <0 0x942f0000 0 0x8000>;
+			no-map;
+		};
+
+		dsp_vdev0vring1: memory@942f8000 {
+			reg = <0 0x942f8000 0 0x8000>;
+			no-map;
+		};
+
+		dsp_vdev0buffer: memory@94300000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x94300000 0 0x100000>;
+			no-map;
+		};
+
+		/* global autoconfigured region for contiguous allocations */
+		linux,cma {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0 0xc0000000 0 0x3c000000>;
+			size = <0 0x3c000000>;
+			linux,cma-default;
+			reusable;
+		};
+	};
+
+	sound-wm8904 {
+		compatible = "simple-audio-card";
+		simple-audio-card,bitclock-master = <&codec_dai>;
+		simple-audio-card,format = "i2s";
+		simple-audio-card,frame-master = <&codec_dai>;
+		simple-audio-card,mclk-fs = <256>;
+		simple-audio-card,name = "wm8904-audio";
+		simple-audio-card,routing =
+			"Headphone Jack", "HPOUTL",
+			"Headphone Jack", "HPOUTR",
+			"IN2L", "Line In Jack",
+			"IN2R", "Line In Jack",
+			"IN1L", "Microphone Jack",
+			"IN1R", "Microphone Jack";
+		simple-audio-card,widgets =
+			"Microphone", "Microphone Jack",
+			"Headphone", "Headphone Jack",
+			"Line", "Line In Jack";
+
+		codec_dai: simple-audio-card,codec {
+			sound-dai = <&wm8904>;
+		};
+
+		simple-audio-card,cpu {
+			sound-dai = <&esai0>;
+		};
+	};
+};
+
+&acm {
+	status = "okay";
+};
+
+&asrc0 {
+	fsl,asrc-rate  = <48000>;
+	status = "okay";
+};
+
+&asrc1 {
+	fsl,asrc-rate = <48000>;
+	status = "okay";
+};
+
+&cm41_intmux {
+	status = "okay";
+};
+
+&esai0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esai0>;
+	#sound-dai-cells = <0>;
+	assigned-clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+			<&esai0_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div0_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <49152000>, <24576000>, <49152000>;
+	status = "okay";
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec1>;
+	/*
+	 * The required RGMII TX and RX 2ns delays are implemented directly
+	 * in hardware via passive delay elements on the SOM PCB.
+	 * No delay configuration is needed in software via PHY driver.
+	 */
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy@4 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <4>;
+			reset-gpios = <&lsio_gpio2 28 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&reg_phy_vddio>;
+		};
+	};
+};
+
+&gpio0_mipi_csi0 {
+	status = "disabled";
+};
+
+&gpio0_mipi_csi1 {
+	status = "disabled";
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c0>;
+	status = "okay";
+
+	wm8904: codec@1a {
+		compatible = "wlf,wm8904";
+		reg = <0x1a>;
+		#sound-dai-cells = <0>;
+		clocks = <&mclkout0_lpcg 0>;
+		clock-names = "mclk";
+		assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+				<&mclkout0_lpcg 0>;
+		assigned-clock-rates = <786432000>, <49152000>, <12288000>, <12288000>;
+		AVDD-supply = <&reg_audio_supply>;
+		CPVDD-supply = <&reg_audio_supply>;
+		DBVDD-supply = <&reg_audio_supply>;
+		DCVDD-supply = <&reg_audio_supply>;
+		MICVDD-supply = <&reg_audio_supply>;
+		wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+				    "soft", "music";
+		/*
+		 * Config registers per name, respectively:
+		 * KNEE_IP = 0,   KNEE_OP = 0,     HI_COMP = 1,   LO_COMP = 1
+		 * KNEE_IP = -24, KNEE_OP = -6,    HI_COMP = 1/4, LO_COMP = 1
+		 * KNEE_IP = -42, KNEE_OP = -3,    HI_COMP = 0,   LO_COMP = 1
+		 * KNEE_IP = -45, KNEE_OP = -9,    HI_COMP = 1/8, LO_COMP = 1
+		 * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+		 */
+		wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+				   /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+				   /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+				   /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+				   /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+		/* GPIO1 = DMIC_CLK, don't touch others */
+		wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+	};
+};
+
+/* Bluetooth */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&mu_m0{
+	status = "okay";
+};
+
+&mu1_m0{
+	status = "okay";
+};
+
+&mu2_m0{
+	status = "okay";
+};
+
+&rtc {
+	status = "disabled";
+};
+
+&sai6 {
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI6_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai6_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&sai7 {
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI7_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai7_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&thermal_zones {
+	pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;
+				type = "critical";
+			};
+		};
+		cooling-maps {
+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+	};
+};
+
+/* eMMC */
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+/* WIFI */
+&usdhc3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
+	bus-width = <4>;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	pinctrl_esai0: esai0grp {
+		fsl,pins = <
+			IMX8QM_ESAI0_FSR_AUD_ESAI0_FSR				0xc6000040
+			IMX8QM_ESAI0_FST_AUD_ESAI0_FST				0xc6000040
+			IMX8QM_ESAI0_SCKR_AUD_ESAI0_SCKR			0xc6000040
+			IMX8QM_ESAI0_SCKT_AUD_ESAI0_SCKT			0xc6000040
+			IMX8QM_ESAI0_TX0_AUD_ESAI0_TX0				0xc6000040
+			IMX8QM_ESAI0_TX5_RX0_AUD_ESAI0_TX5_RX0			0xc6000040
+			IMX8QM_MCLK_OUT0_AUD_ESAI0_TX_HF_CLK			0xc600004c
+		>;
+	};
+
+	pinctrl_fec1: fec1grp {
+		fsl,pins = <
+			IMX8QM_ENET0_MDC_CONN_ENET0_MDC				0x06000048
+			IMX8QM_ENET0_MDIO_CONN_ENET0_MDIO			0x06000048
+			IMX8QM_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL	0x06000048
+			IMX8QM_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC		0x06000048
+			IMX8QM_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0		0x06000048
+			IMX8QM_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1		0x06000048
+			IMX8QM_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2		0x06000048
+			IMX8QM_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3		0x06000048
+			IMX8QM_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC		0x06000048
+			IMX8QM_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL	0x06000048
+			IMX8QM_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0		0x06000048
+			IMX8QM_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1		0x06000048
+			IMX8QM_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2		0x06000048
+			IMX8QM_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3		0x06000048
+			IMX8QM_ESAI0_TX2_RX3_LSIO_GPIO2_IO28			0x06000028
+			IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30			0x06000048
+		>;
+	};
+
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			IMX8QM_ESAI1_FSR_LSIO_GPIO2_IO04			0x00000041
+			IMX8QM_ESAI1_FST_LSIO_GPIO2_IO05			0x00000041
+			IMX8QM_ESAI1_SCKR_LSIO_GPIO2_IO06			0x00000041
+			IMX8QM_ESAI1_SCKT_LSIO_GPIO2_IO07			0x00000041
+			IMX8QM_SPDIF0_EXT_CLK_LSIO_GPIO2_IO16			0x00000041
+		>;
+	};
+
+	pinctrl_i2c0: i2c0grp {
+		fsl,pins = <
+			IMX8QM_HDMI_TX0_TS_SCL_DMA_I2C0_SCL			0xc6000020
+			IMX8QM_HDMI_TX0_TS_SDA_DMA_I2C0_SDA			0xc6000020
+		>;
+	};
+
+	pinctrl_lpuart1: lpuart1grp {
+		fsl,pins = <
+			IMX8QM_UART1_RX_DMA_UART1_RX				0x06000020
+			IMX8QM_UART1_TX_DMA_UART1_TX				0x06000020
+			IMX8QM_UART1_CTS_B_DMA_UART1_RTS_B			0x06000020
+			IMX8QM_UART1_RTS_B_DMA_UART1_CTS_B			0x06000020
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK				0x06000041
+			IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD				0x00000021
+			IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0			0x00000021
+			IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1			0x00000021
+			IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2			0x00000021
+			IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3			0x00000021
+			IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4			0x00000021
+			IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5			0x00000021
+			IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6			0x00000021
+			IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7			0x00000021
+			IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE			0x06000041
+			IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B			0x00000021
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+		fsl,pins = <
+			IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK				0x06000040
+			IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD				0x00000020
+			IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0			0x00000020
+			IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1			0x00000020
+			IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2			0x00000020
+			IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3			0x00000020
+			IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4			0x00000020
+			IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5			0x00000020
+			IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6			0x00000020
+			IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7			0x00000020
+			IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE			0x06000040
+			IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B			0x00000020
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+		fsl,pins = <
+			IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK				0x06000040
+			IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD				0x00000020
+			IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0			0x00000020
+			IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1			0x00000020
+			IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2			0x00000020
+			IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3			0x00000020
+			IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4			0x00000020
+			IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5			0x00000020
+			IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6			0x00000020
+			IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7			0x00000020
+			IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE			0x06000040
+			IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B			0x00000020
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK			0x06000041
+			IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD			0x00000021
+			IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0			0x00000021
+			IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1			0x00000021
+			IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2			0x00000021
+			IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3			0x00000021
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3100mhzgrp {
+		fsl,pins = <
+			IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK			0x06000040
+			IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD			0x00000020
+			IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0			0x00000020
+			IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1			0x00000020
+			IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2			0x00000020
+			IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3			0x00000020
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK			0x06000040
+			IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD			0x00000020
+			IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0			0x00000020
+			IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1			0x00000020
+			IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2			0x00000020
+			IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3			0x00000020
+		>;
+	};
+
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
+			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
+			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
+			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
+		>;
+	};
+};

Signature · 1 line

2.47.3

[email protected]

AI review

2026-06-30 10:07 UTC #4 lore raw

Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Wi-Fi and Bluetooth on the SOM will fail to probe because their enable GPIOs are never toggled and the Wi-Fi MMC host lacks the non-removable property.
- [High] Incomplete PMIC cooling map omits high-power A72 cores.
- [Medium] Missing PHY interrupt configuration causes fallback to polling.
--

commit c50bb64cb8cb31c1a2367dc07bbf18802022b684
Author: Stefano Radaelli <[email protected]>
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

This commit adds device tree support for the Variscite VAR-SOM-MX8 QuadMax system on module. It enables basic on-module peripherals including memory, ethernet, audio, and Wi-Fi/Bluetooth functionality.

Link https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/

Quoted 5 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +0 -0
new file mode 100644
index 0000000000000..2ffc32ddbf51e

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 215

Quoted 12 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +12 -0

+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy@4 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <4>;
+			reset-gpios = <&lsio_gpio2 28 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&reg_phy_vddio>;
+		};

[Severity: Medium]
In pinctrl_fec1 below, the pin IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30 is muxed alongside the Ethernet reset pin, suggesting it is intended as the PHY interrupt pin. However, this ethphy0 node does not declare an interrupts property. Will the network stack fall back to polling the PHY over the MDIO bus, wasting CPU cycles and increasing link-state detection latency?

Quoted 2 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+	};
+};

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 275

Quoted 7 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0

+/* Bluetooth */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	uart-has-rtscts;
+	status = "okay";
+};

[Severity: High]
The commit message states the SOM includes Bluetooth, but this lpuart1 node lacks a bluetooth child node to power on the Bluetooth chip. Since the required GPIOs are muxed in pinctrl_wifi below but never actively driven, will the Bluetooth chip remain in reset and fail to probe?

[ ... ]

Quoted 18 lines

+&thermal_zones {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +17 -0

+	pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;
+				type = "critical";
+			};
+		};
+		cooling-maps {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 344

Quoted 10 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0

+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+	};
+};

[Severity: High]
The i.MX8QM processor has both A53 and A72 cores, but the cooling-device list only includes the four low-power Cortex-A53 cores. If a heavy workload on the high-power Cortex-A72 cores causes the PMIC to overheat, will the thermal framework fail to throttle the A72 cores, risking hardware damage or sudden thermal shutdowns?

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 366

Quoted 10 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0

+/* WIFI */
+&usdhc3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
+	bus-width = <4>;
+	status = "okay";

[Severity: High]
This usdhc3 node lacks the non-removable property and an mmc-pwrseq to toggle the reset GPIO. Because the Wi-Fi chip is soldered and lacks a card-detect pin, will the MMC subsystem treat it as a removable card, fail to detect it, and not probe the interface?

Quoted 6 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +6 -0
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+	};
+};

[ ... ]

Quoted 2 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+	pinctrl_fec1: fec1grp {
+		fsl,pins = <

[ ... ]

Quoted 4 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+			IMX8QM_ESAI0_TX2_RX3_LSIO_GPIO2_IO28			0x06000028
+			IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30			0x06000048
+		>;
+	};

[ ... ]

Quoted 9 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +9 -0

+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
+			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
+			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
+			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
+		>;
+	};
+};

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

Frank Li

2026-07-13 15:28 UTC #5 lore raw

Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Quoted 33 lines · On Tue, Jun 30, 2026 at 10:07:11AM +0000, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Wi-Fi and Bluetooth on the SOM will fail to probe because their enable GPIOs are never toggled and the Wi-Fi MMC host lacks the non-removable property.
- [High] Incomplete PMIC cooling map omits high-power A72 cores.
- [Medium] Missing PHY interrupt configuration causes fallback to polling.
--
commit c50bb64cb8cb31c1a2367dc07bbf18802022b684
Author: Stefano Radaelli <[email protected]>
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax
This commit adds device tree support for the Variscite VAR-SOM-MX8 QuadMax system on module. It enables basic on-module peripherals including memory, ethernet, audio, and Wi-Fi/Bluetooth functionality.
Link https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +0 -0
new file mode 100644
index 0000000000000..2ffc32ddbf51e
[ ... ]
Quoted 11 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +11 -0
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy@4 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <4>;
+			reset-gpios = <&lsio_gpio2 28 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&reg_phy_vddio>;

Quoted 9 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi
Quoted 1 line
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +1 -0
+		};
[Severity: Medium]
In pinctrl_fec1 below, the pin IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30 is muxed alongside the Ethernet reset pin, suggesting it is intended as the PHY interrupt pin. However, this ethphy0 node does not declare an interrupts property. Will the network stack fall back to polling the PHY over the MDIO bus, wasting CPU cycles and increasing link-state detection latency?

Please check it.

Quoted 55 lines

Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+	};
+};
[ ... ]
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 275
Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+/* Bluetooth */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	uart-has-rtscts;
+	status = "okay";
+};
[Severity: High]
The commit message states the SOM includes Bluetooth, but this lpuart1 node lacks a bluetooth child node to power on the Bluetooth chip. Since the required GPIOs are muxed in pinctrl_wifi below but never actively driven, will the Bluetooth chip remain in reset and fail to probe?
[ ... ]
Quoted 18 lines
+&thermal_zones {
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +17 -0
+	pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;
+				type = "critical";
+			};
+		};
+		cooling-maps {
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 344
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+	};
+};
[Severity: High]
The i.MX8QM processor has both A53 and A72 cores, but the cooling-device list only includes the four low-power Cortex-A53 cores. If a heavy workload on the high-power Cortex-A72 cores causes the PMIC to overheat, will the thermal framework fail to throttle the A72 cores, risking hardware damage or sudden thermal shutdowns?
[ ... ]

Quoted 16 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 366
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+/* WIFI */
+&usdhc3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
+	bus-width = <4>;
+	status = "okay";
[Severity: High]
This usdhc3 node lacks the non-removable property and an mmc-pwrseq to toggle the reset GPIO. Because the Wi-Fi chip is soldered and lacks a card-detect pin, will the MMC subsystem treat it as a removable card, fail to detect it, and not probe the interface?

Please check it!

Frank

Quoted 29 lines

Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +6 -0
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+	};
+};
[ ... ]
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+	pinctrl_fec1: fec1grp {
+		fsl,pins = <
[ ... ]
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+			IMX8QM_ESAI0_TX2_RX3_LSIO_GPIO2_IO28			0x06000028
+			IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30			0x06000048
+		>;
+	};
[ ... ]
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 529
Quoted 9 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +9 -0
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
+			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
+			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
+			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
+		>;
+	};
+};
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

Stefano Radaelli

author

2026-06-30 09:47 UTC #6 lore raw

PATCH 3/3 arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

In reply to Stefano Radaelli

From: Stefano Radaelli <[email protected]>

Add device tree support for the Variscite Symphony carrier board with the VAR-SOM-MX8 QuadMax system on module.

The Symphony board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
- PCIE support

Link https://variscite.com/carrier-boards/symphony-board/

Signed-off-by Stefano Radaelli <[email protected]>

---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx8qm-var-som-symphony.dts | 488 ++++++++++++++++++
 2 files changed, 489 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts

arch/arm64/boot/dts/freescale/Makefile +1 -0

index 8ddaab127ab9..118674f0ce7e 100644
@@ -528,6 +528,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.1.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.2.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qm-mek.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qm-tqma8qm-mba8x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qm-var-som-symphony.dtb
 
 imx8qm-mek-ov5640-csi0-dtbs := imx8qm-mek.dtb imx8qm-mek-ov5640-csi0.dtbo
 dtb-${CONFIG_ARCH_MXC} += imx8qm-mek-ov5640-csi0.dtb

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +488 -0

488 lines not on this page · raw message

Signature · 1 line

2.47.3

[email protected]

AI review

2026-06-30 10:21 UTC #7 lore raw

Re: [PATCH v1 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] The PTN5150 USB Type-C controller's interrupt is incorrectly configured as active-high…

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The PTN5150 USB Type-C controller's interrupt is incorrectly configured as active-high (IRQ_TYPE_LEVEL_HIGH), which will cause an interrupt storm.
- [Medium] The SPI chip select GPIO is configured as active-high by mistake, breaking standard SPI devices.
--

commit 640b696a79494ebf66cec9e81eee16f6d3d56651

Author: Stefano Radaelli <[email protected]>
Date:   Tue Jun 30 09:46:56 2026 +0000

arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

Add device tree support for the Variscite Symphony carrier board with the VAR-SOM-MX8 QuadMax system on module.

Link https://variscite.com/carrier-boards/symphony-board/

Quoted 4 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +0 -0
new file mode 100644

[ ... ]

Quoted 15 lines

+&i2c1 {

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +14 -0

+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+
+	pca9534: gpio@20 {
+		compatible = "nxp,pca9534";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9534>;
+		interrupt-parent = <&lsio_gpio1>;
+		interrupts = <24 IRQ_TYPE_LEVEL_LOW>;

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts line 206

Quoted 10 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +10 -0

+	};
+
+	/* USB Type-C Controller */
+	typec_ptn5150: typec@3d {
+		compatible = "nxp,ptn5150";
+		reg = <0x3d>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ptn5150>;
+		interrupt-parent = <&lsio_gpio3>;
+		interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Will this active-high interrupt polarity cause an interrupt storm at boot?

The PTN5150 hardware pin INTB is open-drain and active-low, which means it idles high. By configuring the interrupt trigger as IRQ_TYPE_LEVEL_HIGH, the kernel expects an active-high signal. Since the idle state is high, the interrupt will fire continuously as long as it is idle.

Other Variscite Symphony board DTs correctly configure this identical component's interrupt as IRQ_TYPE_LEVEL_LOW.

Quoted 8 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +8 -0
+
+		port {
+			typec_dr_sw: endpoint {
+				remote-endpoint = <&usb3_drd_sw>;
+			};
+		};
+	};
+};

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts line 272

Quoted 6 lines

+&lpspi1 {
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +5 -0
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpspi1>;
+	cs-gpios = <&lsio_gpio3 24 0>;

[Severity: Medium]
Does this active-high chip select polarity break standard SPI devices attached to the bus?

Standard SPI chip selects are active-low, expecting the line to go low to select the peripheral. By setting the cs-gpios polarity to 0 (GPIO_ACTIVE_HIGH), the SPI subsystem will drive the pin logically true (physically HIGH) when asserting CS, and physically LOW when idle.

This means an attached standard SPI device will be continuously selected when idle, leading to bus contention. While gpiolib contains a legacy quirk to rewrite this if a statically defined active-low child node is present at parse time, this quirk will not protect dynamically added devices.

Should this be updated to use GPIO_ACTIVE_LOW to match standard SPI behavior?

Quoted 2 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +2 -0
+	status = "okay";
+};

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

Frank Li

2026-07-13 15:29 UTC #8 lore raw

Re: [PATCH v1 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

Quoted 52 lines · On Tue, Jun 30, 2026 at 10:21:08AM +0000, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The PTN5150 USB Type-C controller's interrupt is incorrectly configured as active-high (IRQ_TYPE_LEVEL_HIGH), which will cause an interrupt storm.
- [Medium] The SPI chip select GPIO is configured as active-high by mistake, breaking standard SPI devices.
--
commit 640b696a79494ebf66cec9e81eee16f6d3d56651
Author: Stefano Radaelli <[email protected]>
Date:   Tue Jun 30 09:46:56 2026 +0000
arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board
Add device tree support for the Variscite Symphony carrier board with the VAR-SOM-MX8 QuadMax system on module.
Link https://variscite.com/carrier-boards/symphony-board/
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +0 -0
new file mode 100644
[ ... ]
Quoted 15 lines
+&i2c1 {
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +14 -0
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+
+	pca9534: gpio@20 {
+		compatible = "nxp,pca9534";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9534>;
+		interrupt-parent = <&lsio_gpio1>;
+		interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts line 206
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +10 -0
+	};
+
+	/* USB Type-C Controller */
+	typec_ptn5150: typec@3d {
+		compatible = "nxp,ptn5150";
+		reg = <0x3d>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ptn5150>;
+		interrupt-parent = <&lsio_gpio3>;
+		interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
[Severity: High]
Will this active-high interrupt polarity cause an interrupt storm at boot?

Quoted 8 lines

The PTN5150 hardware pin INTB is open-drain and active-low, which means it idles high. By configuring the interrupt trigger as IRQ_TYPE_LEVEL_HIGH, the kernel expects an active-high signal. Since the idle state is high, the interrupt will fire continuously as long as it is idle.
Other Variscite Symphony board DTs correctly configure this identical component's interrupt as IRQ_TYPE_LEVEL_LOW.

Make sense, please check it.

Quoted 27 lines

Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +8 -0
+
+		port {
+			typec_dr_sw: endpoint {
+				remote-endpoint = <&usb3_drd_sw>;
+			};
+		};
+	};
+};
[ ... ]
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts line 272
Quoted 6 lines
+&lpspi1 {
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +5 -0
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpspi1>;
+	cs-gpios = <&lsio_gpio3 24 0>;
[Severity: Medium]
Does this active-high chip select polarity break standard SPI devices attached to the bus?
Standard SPI chip selects are active-low, expecting the line to go low to select the peripheral. By setting the cs-gpios polarity to 0 (GPIO_ACTIVE_HIGH), the SPI subsystem will drive the pin logically true (physically HIGH) when asserting CS, and physically LOW when idle.

Quoted 8 lines

This means an attached standard SPI device will be continuously selected when idle, leading to bus contention. While gpiolib contains a legacy quirk to rewrite this if a statically defined active-low child node is present at parse time, this quirk will not protect dynamically added devices.
Should this be updated to use GPIO_ACTIVE_LOW to match standard SPI behavior?

make sense, please check it

Frank

Quoted 6 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
Quoted 3 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +2 -0
+	status = "okay";
+};
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3