[PATCH v1 00/11] arm64: dts: freescale: imx8mm-var-som: Align SOM and Symphony DTSs

[PATCH v1 00/11] arm64: dts: freescale: imx8mm-var-som: Align SOM and Symphony DTSs

[Stefano Radaelli]

This series aligns the i.MX8MM VAR-SOM and VAR-SOM Symphony device
trees with the latest hardware revisions.

The update consolidates the device tree descriptions to better reflect
the actual hardware partitioning between the SOM and the carrier board.
Nodes describing peripherals physically present on the SOM are kept in
the SOM dtsi, while carrier-specific components are described in the
corresponding carrier dts.

The changes were tested on the latest VAR-SOM and Symphony hardware
revision.

Stefano Radaelli (11):
  arm64: dts: imx8mm-var-som: Move UART4 description to Symphony carrier
  arm64: dts: freescale: imx8mm-var-som: Align fsl,pins tables
  arm64: dts: freescale: imx8mm-var-som: Update FEC support with
    MaxLinear PHY
  arm64: dts: imx8mm-var-som: Add support for WM8904 audio codec
  arm64: dts: freescale: imx8mm-var-som: Add MCP251xFD CAN controller
  arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
  arm64: dts: imx8mm-var-som-symphony: Move USB configuration from SOM
  arm64: dts: imx8mm-var-som-symphony: Enable uSD on USDHC2
  arm64: dts: imx8mm-var-som-symphony: Add TPM2 support
  arm64: dts: freescale: imx8mm-var-som-symphony: Enable I2C4
  arm64: dts: imx8mm-var-som-symphony: Enable PCIe

 .../dts/freescale/imx8mm-var-som-symphony.dts | 206 ++++++++-
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 420 ++++++++++++------
 2 files changed, 474 insertions(+), 152 deletions(-)


base-commit: 37a93dd5c49b5fda807fd204edf2547c3493319c
-- 
2.47.3

[PATCH v1 01/11] arm64: dts: imx8mm-var-som: Move UART4 description to Symphony carrier

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

The VAR-SOM-MX8MM module does not provide an onboard debug console.
UART4 is routed and exposed only on the Symphony carrier board, while
custom carrier designs may choose to expose a different UART.

Move the UART4 node from the SOM device tree to the
imx8mm-var-som-symphony.dts, keeping the SOM dtsi limited to hardware
present on the module itself.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../dts/freescale/imx8mm-var-som-symphony.dts  | 18 ++++++++++++++++++
 .../boot/dts/freescale/imx8mm-var-som.dtsi     | 18 ------------------
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index affbc67c2ef6..819707e6f3bf 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -11,6 +11,10 @@ / {
 	model = "Variscite VAR-SOM-MX8MM Symphony evaluation board";
 	compatible = "variscite,var-som-mx8mm-symphony", "variscite,var-som-mx8mm", "fsl,imx8mm";
 
+	chosen {
+		stdout-path = &uart4;
+	};
+
 	reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -156,6 +160,13 @@ &uart3 {
 	status = "okay";
 };
 
+/* Console */
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
 &usbotg1 {
 	disable-over-current;
 	extcon = <&extcon_usbotg1>, <&extcon_usbotg1>;
@@ -251,4 +262,11 @@ MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX	0x140
 			MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX	0x140
 		>;
 	};
+
+	pinctrl_uart4: uart4grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX	0x140
+			MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX	0x140
+		>;
+	};
 };
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index 190bde4edcd7..b6560c03639e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -9,10 +9,6 @@
 / {
 	model = "Variscite VAR-SOM-MX8MM module";
 
-	chosen {
-		stdout-path = &uart4;
-	};
-
 	memory@40000000 {
 		device_type = "memory";
 		reg = <0x0 0x40000000 0 0x80000000>;
@@ -274,13 +270,6 @@ &uart2 {
 	status = "okay";
 };
 
-/* Console */
-&uart4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart4>;
-	status = "okay";
-};
-
 &usbotg1 {
 	dr_mode = "otg";
 	usb-role-switch;
@@ -418,13 +407,6 @@ MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B	0x140
 		>;
 	};
 
-	pinctrl_uart4: uart4grp {
-		fsl,pins = <
-			MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX	0x140
-			MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX	0x140
-		>;
-	};
-
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK		0x190
-- 
2.47.3

[PATCH v1 02/11] arm64: dts: freescale: imx8mm-var-som: Align fsl,pins tables

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Reformat the fsl,pins tables in the i.MX8MM VAR-SOM device tree to use
consistent column alignment across all pinctrl groups.

Align the entries to match the formatting already used in the
pinctrl_fec1 group, which contains the longest pin definitions,
for improved readability and consistency.

No functional changes intended.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 170 +++++++++---------
 1 file changed, 85 insertions(+), 85 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index b6560c03639e..da3c7332ec34 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -368,171 +368,171 @@ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19
 
 	pinctrl_i2c1: i2c1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL		0x400001c3
-			MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA		0x400001c3
+			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x400001c3
+			MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA			0x400001c3
 		>;
 	};
 
 	pinctrl_i2c3: i2c3grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL		0x400001c3
-			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA		0x400001c3
+			MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL			0x400001c3
+			MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
 		>;
 	};
 
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8	0x141
+			MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8		0x141
 		>;
 	};
 
 	pinctrl_reg_eth_phy: regethphygrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD1_DATA7_GPIO2_IO9	0x41
+			MX8MM_IOMUXC_SD1_DATA7_GPIO2_IO9		0x41
 		>;
 	};
 
 	pinctrl_restouch: restouchgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3	0x1c0
+			MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x1c0
 		>;
 	};
 
 	pinctrl_uart2: uart2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX	0x140
-			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX	0x140
-			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B	0x140
-			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B	0x140
+			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x140
+			MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX		0x140
+			MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B		0x140
+			MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B		0x140
 		>;
 	};
 
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK		0x190
-			MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD		0x1d0
-			MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0	0x1d0
-			MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1	0x1d0
-			MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2	0x1d0
-			MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3	0x1d0
+			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK			0x190
+			MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD			0x1d0
+			MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0		0x1d0
+			MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1		0x1d0
+			MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2		0x1d0
+			MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3		0x1d0
 		>;
 	};
 
 	pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK		0x194
-			MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD		0x1d4
-			MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0	0x1d4
-			MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1	0x1d4
-			MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2	0x1d4
-			MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3	0x1d4
+			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK			0x194
+			MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD			0x1d4
+			MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0		0x1d4
+			MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1		0x1d4
+			MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2		0x1d4
+			MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3		0x1d4
 		>;
 	};
 
 	pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK		0x196
-			MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD		0x1d6
-			MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0	0x1d6
-			MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1	0x1d6
-			MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2	0x1d6
-			MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3	0x1d6
+			MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK			0x196
+			MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD			0x1d6
+			MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0		0x1d6
+			MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1		0x1d6
+			MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2		0x1d6
+			MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3		0x1d6
 		>;
 	};
 
 	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10	0xc1
+			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10		0xc1
 		>;
 	};
 
 	pinctrl_usdhc2: usdhc2grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK		0x190
-			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD		0x1d0
-			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0	0x1d0
-			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1	0x1d0
-			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2	0x1d0
-			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3	0x1d0
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT	0x1d0
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x190
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d0
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d0
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d0
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d0
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d0
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
 		>;
 	};
 
 	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK		0x194
-			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD		0x1d4
-			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0	0x1d4
-			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1	0x1d4
-			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2	0x1d4
-			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3	0x1d4
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT	0x1d0
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x194
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d4
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d4
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d4
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d4
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d4
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
 		>;
 	};
 
 	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK		0x196
-			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD		0x1d6
-			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0	0x1d6
-			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1	0x1d6
-			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2	0x1d6
-			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3	0x1d6
-			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT	0x1d0
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK			0x196
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD			0x1d6
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0		0x1d6
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1		0x1d6
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2		0x1d6
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3		0x1d6
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0x1d0
 		>;
 	};
 
 	pinctrl_usdhc3: usdhc3grp {
 		fsl,pins = <
-			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK	0x190
-			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD	0x1d0
-			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0	0x1d0
-			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1	0x1d0
-			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2	0x1d0
-			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3	0x1d0
-			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4	0x1d0
-			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5	0x1d0
-			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6	0x1d0
-			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7	0x1d0
-			MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE	0x190
+			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x190
+			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x1d0
+			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x1d0
+			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x1d0
+			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x1d0
+			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x1d0
+			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x1d0
+			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x1d0
+			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x1d0
+			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x1d0
+			MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE		0x190
 		>;
 	};
 
 	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK	0x194
-			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD	0x1d4
-			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0	0x1d4
-			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1	0x1d4
-			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2	0x1d4
-			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3	0x1d4
-			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4	0x1d4
-			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5	0x1d4
-			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6	0x1d4
-			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7	0x1d4
-			MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE	0x194
+			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x194
+			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x1d4
+			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x1d4
+			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x1d4
+			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x1d4
+			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x1d4
+			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x1d4
+			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x1d4
+			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x1d4
+			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x1d4
+			MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE		0x194
 		>;
 	};
 
 	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK	0x196
-			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD	0x1d6
-			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0	0x1d6
-			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1	0x1d6
-			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2	0x1d6
-			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3	0x1d6
-			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4	0x1d6
-			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5	0x1d6
-			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6	0x1d6
-			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7	0x1d6
-			MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE	0x196
+			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x196
+			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x1d6
+			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x1d6
+			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x1d6
+			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x1d6
+			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x1d6
+			MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4		0x1d6
+			MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5		0x1d6
+			MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6		0x1d6
+			MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7		0x1d6
+			MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE		0x196
 		>;
 	};
 
 	pinctrl_wdog: wdoggrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B	0x166
+			MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B		0x166
 		>;
 	};
 };
-- 
2.47.3

[PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Update the FEC Ethernet controller on the i.MX8MM VAR-SOM to match the
latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.

This patch adds:
- PHY VDDIO 1.8V supply regulator.
- Proper reset timings for the MXL86110.
- LED configuration for link/activity indication via the LED subsystem
  under /sys/class/leds/, leveraging the support in the MXL86110 PHY
  driver.
  Two LEDs are defined to match the VAR-SOM carrier design:
    * LED@0: Yellow, netdev trigger.
    * LED@1: Green, netdev trigger.
- A pinctrl sleep state for low-power operation.

The PHY reset is now handled in the SOM .dtsi using the SoC GPIO.
The previous carrier-specific reset-gpios property in the Symphony
device tree is therefore removed.

The enet_rst GPIO hog on the carrier is kept to ensure a defined
board-level reset line state during boot.

Wake-on-LAN via magic packet is not supported at the VAR-SOM level and
is therefore not enabled in the SOM device tree nor in the official
evaluation carrier board configuration (symphony).
Designs requiring WoL support may enable it in their own carrier-specific
device trees if properly integrated at the hardware level.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../dts/freescale/imx8mm-var-som-symphony.dts | 11 ++--
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 59 ++++++++++++++++++-
 2 files changed, 63 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 819707e6f3bf..689894405b27 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -70,10 +70,6 @@ led {
 	};
 };
 
-&ethphy {
-	reset-gpios = <&pca9534 5 GPIO_ACTIVE_HIGH>;
-};
-
 &i2c2 {
 	clock-frequency = <400000>;
 	pinctrl-names = "default";
@@ -99,6 +95,13 @@ usb3-sata-sel-hog {
 			line-name = "usb3_sata_sel";
 		};
 
+		enet-rst-hog {
+			gpio-hog;
+			gpios = <5 GPIO_ACTIVE_HIGH>;
+			output-low;
+			line-name = "enet_rst";
+		};
+
 		som-vselect-hog {
 			gpio-hog;
 			gpios = <6 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index da3c7332ec34..23045f54e00e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -4,6 +4,7 @@
  * Copyright (C) 2020 Krzysztof Kozlowski <krzk@kernel.org>
  */
 
+#include <dt-bindings/leds/common.h>
 #include "imx8mm.dtsi"
 
 / {
@@ -24,6 +25,13 @@ reg_eth_phy: regulator-eth-phy {
 		gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>;
 		enable-active-high;
 	};
+
+	reg_phy_vddio: regulator-phy-vddio {
+		compatible = "regulator-fixed";
+		regulator-name = "vddio-1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
 };
 
 &A53_0 {
@@ -99,12 +107,17 @@ touchscreen@0 {
 };
 
 &fec1 {
-	pinctrl-names = "default";
+	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&pinctrl_fec1>;
+	pinctrl-1 = <&pinctrl_fec1_sleep>;
+	/*
+	 * 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 = <&ethphy>;
 	phy-supply = <&reg_eth_phy>;
-	fsl,magic-packet;
 	status = "okay";
 
 	mdio {
@@ -116,7 +129,27 @@ ethphy: ethernet-phy@4 {
 			reg = <4>;
 			reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
 			reset-assert-us = <10000>;
-			reset-deassert-us = <10000>;
+			reset-deassert-us = <100000>;
+			vddio-supply = <&reg_phy_vddio>;
+
+			leds {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				led@0 {
+					reg = <0>;
+					color = <LED_COLOR_ID_YELLOW>;
+					function = LED_FUNCTION_LAN;
+					linux,default-trigger = "netdev";
+				};
+
+				led@1 {
+					reg = <1>;
+					color = <LED_COLOR_ID_GREEN>;
+					function = LED_FUNCTION_LAN;
+					linux,default-trigger = "netdev";
+				};
+			};
 		};
 	};
 };
@@ -366,6 +399,26 @@ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x19
 		>;
 	};
 
+	pinctrl_fec1_sleep: fec1sleepgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_ENET_MDC_GPIO1_IO16		0x120
+			MX8MM_IOMUXC_ENET_MDIO_GPIO1_IO17		0x120
+			MX8MM_IOMUXC_ENET_TD3_GPIO1_IO18		0x120
+			MX8MM_IOMUXC_ENET_TD2_GPIO1_IO19		0x120
+			MX8MM_IOMUXC_ENET_TD1_GPIO1_IO20		0x120
+			MX8MM_IOMUXC_ENET_TD0_GPIO1_IO21		0x120
+			MX8MM_IOMUXC_ENET_RD3_GPIO1_IO29		0x120
+			MX8MM_IOMUXC_ENET_RD2_GPIO1_IO28		0x120
+			MX8MM_IOMUXC_ENET_RD1_GPIO1_IO27		0x120
+			MX8MM_IOMUXC_ENET_RD0_GPIO1_IO26		0x120
+			MX8MM_IOMUXC_ENET_TXC_GPIO1_IO23		0x120
+			MX8MM_IOMUXC_ENET_RXC_GPIO1_IO25		0x120
+			MX8MM_IOMUXC_ENET_RX_CTL_GPIO1_IO24		0x120
+			MX8MM_IOMUXC_ENET_TX_CTL_GPIO1_IO22		0x120
+			MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9		0x100
+		>;
+	};
+
 	pinctrl_i2c1: i2c1grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL			0x400001c3
-- 
2.47.3

Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Andrew Lunn]

On Tue, Feb 17, 2026 at 07:42:37PM +0100, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
> 
> Update the FEC Ethernet controller on the i.MX8MM VAR-SOM to match the
> latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.

I don't think you say this explicitly anywhere, so i will ask. The PHY
is on the SOM? The carrier just has magnetics and the RJ45?

>   Two LEDs are defined to match the VAR-SOM carrier design:
>     * LED@0: Yellow, netdev trigger.
>     * LED@1: Green, netdev trigger.

Where are the LEDs? You say "carrier design", so are they on the
carrier? The DT properties should then be in the .dts file for the
carrier.

	Andrew

Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Stefano Radaelli]

Hi Andrew!
> 
> I don't think you say this explicitly anywhere, so i will ask. The PHY
> is on the SOM? The carrier just has magnetics and the RJ45?

Yes, the Ethernet PHY (MXL86110) is physically mounted on the VAR-SOM.
All RGMII signals, MDIO and the LED outputs are routed to the SOM
board-to-board connector. The carrier board only provides the magnetics
and the RJ45 connector.

> 
> >   Two LEDs are defined to match the VAR-SOM carrier design:
> >     * LED@0: Yellow, netdev trigger.
> >     * LED@1: Green, netdev trigger.
> 
> Where are the LEDs? You say "carrier design", so are they on the
> carrier? The DT properties should then be in the .dts file for the
> carrier.
>

The LED signals are driven directly by the PHY and originate on the SOM.
They are exposed on the SOM connector and are typically routed straight
to the RJ45 integrated LEDs on the carrier. For this reason, the LED
configuration belongs in the SOM .dtsi rather than the carrier .dts.

That said, you are right that describing them as "Yellow" and "Green"
ties the description to a specific carrier implementation.
I will drop the `color` property and keep only the LED function and trigger
so that carrier designs can reflect the actual LED implementation if needed.

Does that approach sound acceptable?

As always, thank you for your review.

Best regards,
Stefano

Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Andrew Lunn]

On Tue, Feb 17, 2026 at 08:31:36PM +0100, Stefano Radaelli wrote:
> Hi Andrew!
> > 
> > I don't think you say this explicitly anywhere, so i will ask. The PHY
> > is on the SOM? The carrier just has magnetics and the RJ45?
> 
> Yes, the Ethernet PHY (MXL86110) is physically mounted on the VAR-SOM.

O.K. so far.

> All RGMII signals, MDIO and the LED outputs are routed to the SOM
> board-to-board connector. The carrier board only provides the magnetics
> and the RJ45 connector.

And here you loose me. RGMII is between the MAC and the PHY. The PHY
is on the SOM, so there is no need for RGMII to leave the SOM.

MDIO is can understand going to the carrier, because there can be
other devices on the bus, such as an Ethernet switch.

You say the LEDs are not on the SOM. So they should not be listed in
the .dtsi file for the SOM. It could be the RJ45 is a cheap one,
without LEDs. The colours will depend on the RJ45 socket. It could be
a single LED is connected to the front panel, which is typical of STB
etc. So the LEDs are a board property, not a SOM property.

> > >   Two LEDs are defined to match the VAR-SOM carrier design:
> > >     * LED@0: Yellow, netdev trigger.
> > >     * LED@1: Green, netdev trigger.
> > 
> > Where are the LEDs? You say "carrier design", so are they on the
> > carrier? The DT properties should then be in the .dts file for the
> > carrier.
> >
> 
> The LED signals are driven directly by the PHY and originate on the SOM.
> They are exposed on the SOM connector and are typically routed straight
> to the RJ45 integrated LEDs on the carrier.

The problem here is 'typically', not absolutely required, otherwise
the magic smoke will escape making the box useless.

	Andrew

Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Stefano Radaelli]

Hi Andrew,

On Tue, Feb 17, 2026 at 09:43:16PM +0100, Andrew Lunn wrote:
> 
> And here you loose me. RGMII is between the MAC and the PHY. The PHY
> is on the SOM, so there is no need for RGMII to leave the SOM.
> 
> MDIO is can understand going to the carrier, because there can be
> other devices on the bus, such as an Ethernet switch.
> 
> You say the LEDs are not on the SOM. So they should not be listed in
> the .dtsi file for the SOM. It could be the RJ45 is a cheap one,
> without LEDs. The colours will depend on the RJ45 socket. It could be
> a single LED is connected to the front panel, which is typical of STB
> etc. So the LEDs are a board property, not a SOM property.
> 
> > > >   Two LEDs are defined to match the VAR-SOM carrier design:
> > > >     * LED@0: Yellow, netdev trigger.
> > > >     * LED@1: Green, netdev trigger.
> > > 
> > > Where are the LEDs? You say "carrier design", so are they on the
> > > carrier? The DT properties should then be in the .dts file for the
> > > carrier.
> > >
> > 
> > The LED signals are driven directly by the PHY and originate on the SOM.
> > They are exposed on the SOM connector and are typically routed straight
> > to the RJ45 integrated LEDs on the carrier.
> 
> The problem here is 'typically', not absolutely required, otherwise
> the magic smoke will escape making the box useless.
> 

You are right sorry for the confusion: RGMII is internal between the MAC
and the PHY and does not leave the SOM. What is exposed on the SOM
connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED
output signals.

Given that the actual LEDs are implemented on the carrier side (RJ45
with integrated LEDs, pull-ups and LED supply), would you prefer that
the LED description is moved out of the SOM .dtsi and into the carrier
.dts?

My idea would be to keep the Ethernet controller/PHY node fully
described in the SOM .dtsi (since the PHY is on-module), and add only
the LED subnode/definition in the carrier .dts where the LEDs are
actually present.

If this is the right approach, I will apply the same pattern to the
other Variscite SOMs where we currently describe PHY LEDs at the SOM
level (e.g. imx8mp-var-som, imx93-var-som).

Thanks again for the review.

Best regards,
Stefano

Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Andrew Lunn]

On Wed, Feb 18, 2026 at 09:59:31AM +0100, Stefano Radaelli wrote:
> Hi Andrew,
> 
> On Tue, Feb 17, 2026 at 09:43:16PM +0100, Andrew Lunn wrote:
> > 
> > And here you loose me. RGMII is between the MAC and the PHY. The PHY
> > is on the SOM, so there is no need for RGMII to leave the SOM.
> > 
> > MDIO is can understand going to the carrier, because there can be
> > other devices on the bus, such as an Ethernet switch.
> > 
> > You say the LEDs are not on the SOM. So they should not be listed in
> > the .dtsi file for the SOM. It could be the RJ45 is a cheap one,
> > without LEDs. The colours will depend on the RJ45 socket. It could be
> > a single LED is connected to the front panel, which is typical of STB
> > etc. So the LEDs are a board property, not a SOM property.
> > 
> > > > >   Two LEDs are defined to match the VAR-SOM carrier design:
> > > > >     * LED@0: Yellow, netdev trigger.
> > > > >     * LED@1: Green, netdev trigger.
> > > > 
> > > > Where are the LEDs? You say "carrier design", so are they on the
> > > > carrier? The DT properties should then be in the .dts file for the
> > > > carrier.
> > > >
> > > 
> > > The LED signals are driven directly by the PHY and originate on the SOM.
> > > They are exposed on the SOM connector and are typically routed straight
> > > to the RJ45 integrated LEDs on the carrier.
> > 
> > The problem here is 'typically', not absolutely required, otherwise
> > the magic smoke will escape making the box useless.
> > 
> 
> You are right sorry for the confusion: RGMII is internal between the MAC
> and the PHY and does not leave the SOM. What is exposed on the SOM
> connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED
> output signals.

O.K, that is what i expected.

> Given that the actual LEDs are implemented on the carrier side (RJ45
> with integrated LEDs, pull-ups and LED supply), would you prefer that
> the LED description is moved out of the SOM .dtsi and into the carrier
> .dts?

Yes please.

> My idea would be to keep the Ethernet controller/PHY node fully
> described in the SOM .dtsi (since the PHY is on-module), and add only
> the LED subnode/definition in the carrier .dts where the LEDs are
> actually present.

Yes. That is good.

Thanks
     Andrew

Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY

[Stefano Radaelli]

Hi Andrew,

On Wed, Feb 18, 2026 at 02:23:40PM +0100, Andrew Lunn wrote:
> On Wed, Feb 18, 2026 at 09:59:31AM +0100, Stefano Radaelli wrote:
> > Hi Andrew,
> > 
> > On Tue, Feb 17, 2026 at 09:43:16PM +0100, Andrew Lunn wrote:
> > > 
> > > And here you loose me. RGMII is between the MAC and the PHY. The PHY
> > > is on the SOM, so there is no need for RGMII to leave the SOM.
> > > 
> > > MDIO is can understand going to the carrier, because there can be
> > > other devices on the bus, such as an Ethernet switch.
> > > 
> > > You say the LEDs are not on the SOM. So they should not be listed in
> > > the .dtsi file for the SOM. It could be the RJ45 is a cheap one,
> > > without LEDs. The colours will depend on the RJ45 socket. It could be
> > > a single LED is connected to the front panel, which is typical of STB
> > > etc. So the LEDs are a board property, not a SOM property.
> > > 
> > > > > >   Two LEDs are defined to match the VAR-SOM carrier design:
> > > > > >     * LED@0: Yellow, netdev trigger.
> > > > > >     * LED@1: Green, netdev trigger.
> > > > > 
> > > > > Where are the LEDs? You say "carrier design", so are they on the
> > > > > carrier? The DT properties should then be in the .dts file for the
> > > > > carrier.
> > > > >
> > > > 
> > > > The LED signals are driven directly by the PHY and originate on the SOM.
> > > > They are exposed on the SOM connector and are typically routed straight
> > > > to the RJ45 integrated LEDs on the carrier.
> > > 
> > > The problem here is 'typically', not absolutely required, otherwise
> > > the magic smoke will escape making the box useless.
> > > 
> > 
> > You are right sorry for the confusion: RGMII is internal between the MAC
> > and the PHY and does not leave the SOM. What is exposed on the SOM
> > connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED
> > output signals.
> 
> O.K, that is what i expected.
> 
> > Given that the actual LEDs are implemented on the carrier side (RJ45
> > with integrated LEDs, pull-ups and LED supply), would you prefer that
> > the LED description is moved out of the SOM .dtsi and into the carrier
> > .dts?
> 
> Yes please.
> 
> > My idea would be to keep the Ethernet controller/PHY node fully
> > described in the SOM .dtsi (since the PHY is on-module), and add only
> > the LED subnode/definition in the carrier .dts where the LEDs are
> > actually present.
> 
> Yes. That is good.
> 
> Thanks
>      Andrew


I will send the v2 with led descriptions in Symphony dts instead of SOM
dtsi.

Thank you again,

Best Regards,
Stefano

[PATCH v1 04/11] arm64: dts: imx8mm-var-som: Add support for WM8904 audio codec

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

The VAR-SOM-MX8MM can integrate the WM8904, a high-performance
ultra-low-power stereo codec optimized for portable audio applications.

This patch adds the WM8904 device to the appropriate I2C bus, enables
the SAI peripheral, and introduces the sound node to expose the
sound card to the system.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 101 +++++++++++++++++-
 1 file changed, 98 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index 23045f54e00e..e52080490ddf 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -15,6 +15,14 @@ memory@40000000 {
 		reg = <0x0 0x40000000 0 0x80000000>;
 	};
 
+	reg_audio_supply: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "wm8904-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
 	reg_eth_phy: regulator-eth-phy {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -32,6 +40,34 @@ reg_phy_vddio: regulator-phy-vddio {
 		regulator-min-microvolt = <1800000>;
 		regulator-max-microvolt = <1800000>;
 	};
+
+	sound {
+		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 = <&sai5>;
+		};
+	};
 };
 
 &A53_0 {
@@ -277,18 +313,58 @@ ldo6_reg: LDO6 {
 
 &i2c3 {
 	clock-frequency = <400000>;
-	pinctrl-names = "default";
+	pinctrl-names = "default", "gpio";
 	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_gpio>;
+	scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
 	status = "okay";
 
-	/* TODO: configure audio, as of now just put a placeholder */
 	wm8904: codec@1a {
 		compatible = "wlf,wm8904";
 		reg = <0x1a>;
-		status = "disabled";
+		#sound-dai-cells = <0>;
+		clocks = <&clk IMX8MM_CLK_SAI5_ROOT>;
+		clock-names = "mclk";
+		AVDD-supply = <&ldo5_reg>;
+		CPVDD-supply = <&ldo5_reg>;
+		DBVDD-supply = <&reg_audio_supply>;
+		DCVDD-supply = <&ldo5_reg>;
+		MICVDD-supply = <&ldo5_reg>;
+		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>;
+		status = "okay";
 	};
 };
 
+&sai5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sai5>;
+	assigned-clocks = <&clk IMX8MM_CLK_SAI5>;
+	assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
+	assigned-clock-rates = <1536000>;
+	#sound-dai-cells = <0>;
+	dmas = <&sdma2 8 25 0>, <&sdma2 9 25 0>;
+	dma-names = "rx", "tx";
+	fsl,sai-mclk-direction-output;
+	status = "okay";
+};
+
 &snvs_pwrkey {
 	status = "okay";
 };
@@ -433,6 +509,13 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA			0x400001c3
 		>;
 	};
 
+	pinctrl_i2c3_gpio: i2c3gpiogrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18		0x1c3
+			MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19		0x1c3
+		>;
+	};
+
 	pinctrl_pmic: pmicirqgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8		0x141
@@ -451,6 +534,18 @@ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x1c0
 		>;
 	};
 
+	pinctrl_sai5: sai5grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI5_RXD1_SAI5_TX_SYNC		0xd6
+			MX8MM_IOMUXC_SAI5_RXFS_SAI5_RX_SYNC		0xd6
+			MX8MM_IOMUXC_SAI5_RXD3_SAI5_TX_DATA0		0xd6
+			MX8MM_IOMUXC_SAI5_RXD0_SAI5_RX_DATA0		0xd6
+			MX8MM_IOMUXC_SAI5_RXC_SAI5_RX_BCLK		0xd6
+			MX8MM_IOMUXC_SAI5_RXD2_SAI5_TX_BCLK		0xd6
+			MX8MM_IOMUXC_SAI5_MCLK_SAI5_MCLK		0xd6
+		>;
+	};
+
 	pinctrl_uart2: uart2grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX		0x140
-- 
2.47.3

[PATCH v1 05/11] arm64: dts: freescale: imx8mm-var-som: Add MCP251xFD CAN controller

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Add support for the Microchip MCP251xFD CAN-FD controller connected
to the SPI bus on the i.MX8MM VAR-SOM.

The controller uses a 40 MHz external oscillator and requires an
interrupt line and a dedicated RX interrupt GPIO.

This patch adds the fixed clock, the MCP251xFD device node with the
required properties, and the corresponding pinctrl configuration.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index e52080490ddf..cdcd8faad65e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -15,6 +15,13 @@ memory@40000000 {
 		reg = <0x0 0x40000000 0 0x80000000>;
 	};
 
+	clk40m: oscillator {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <40000000>;
+		clock-output-names = "can_osc";
+	};
+
 	reg_audio_supply: regulator-3p3v {
 		compatible = "regulator-fixed";
 		regulator-name = "wm8904-supply";
@@ -140,6 +147,19 @@ touchscreen@0 {
 		ti,keep-vref-on;
 		wakeup-source;
 	};
+
+	/* CAN controller */
+	can0: can@1 {
+		compatible = "microchip,mcp251xfd";
+		reg = <1>;
+		clocks = <&clk40m>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_can>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+		microchip,rx-int-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+		spi-max-frequency = <20000000>;
+	};
 };
 
 &fec1 {
@@ -445,6 +465,13 @@ &wdog1 {
 };
 
 &iomuxc {
+	pinctrl_can: cangrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x16
+			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x16
+		>;
+	};
+
 	pinctrl_ecspi1: ecspi1grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK		0x13
-- 
2.47.3

[PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Update the WiFi and Bluetooth configuration on the i.MX8MM VAR-SOM
to match the latest SOM hardware revision.

The SOM now integrates an NXP IW61x wireless module. WiFi is connected
via SDIO and Bluetooth via UART.

This patch:
- Adds an mmc-pwrseq node to handle module reset and power sequencing.
- Updates the USDHC1 node to use the new power sequence and required
  pinctrl configuration.
- Adds the Bluetooth child node under UART2.
- Removes the legacy Broadcom WiFi device node.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 41 ++++++++++++++-----
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index cdcd8faad65e..e2b1919d7188 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -22,6 +22,14 @@ clk40m: oscillator {
 		clock-output-names = "can_osc";
 	};
 
+	iw61x_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		post-power-on-delay-ms = <100>;
+		power-off-delay-us = <10000>;
+		reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+			      <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+	};
+
 	reg_audio_supply: regulator-3p3v {
 		compatible = "regulator-fixed";
 		regulator-name = "wm8904-supply";
@@ -392,11 +400,15 @@ &snvs_pwrkey {
 /* Bluetooth */
 &uart2 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart2>;
+	pinctrl-0 = <&pinctrl_uart2>, <&pinctrl_bt>;
 	assigned-clocks = <&clk IMX8MM_CLK_UART2>;
 	assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
 	uart-has-rtscts;
 	status = "okay";
+
+	bluetooth_iw61x: bluetooth {
+		compatible = "nxp,88w8987-bt";
+	};
 };
 
 &usbotg1 {
@@ -413,21 +425,15 @@ &usbotg2 {
 
 /* WIFI */
 &usdhc1 {
-	#address-cells = <1>;
-	#size-cells = <0>;
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
-	pinctrl-0 = <&pinctrl_usdhc1>;
-	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
-	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_wifi>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_wifi>;
 	bus-width = <4>;
 	non-removable;
 	keep-power-in-suspend;
+	mmc-pwrseq = <&iw61x_pwrseq>;
 	status = "okay";
-
-	brcmf: wifi@1 {
-		reg = <1>;
-		compatible = "brcm,bcm4329-fmac";
-	};
 };
 
 /* SD */
@@ -465,6 +471,12 @@ &wdog1 {
 };
 
 &iomuxc {
+	pinctrl_bt: bluetoothgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6		0xc1
+		>;
+	};
+
 	pinctrl_can: cangrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x16
@@ -710,4 +722,11 @@ pinctrl_wdog: wdoggrp {
 			MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B		0x166
 		>;
 	};
+
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_WP_GPIO2_IO20			0x140
+			MX8MM_IOMUXC_SD1_RESET_B_GPIO2_IO10		0xc1
+		>;
+	};
 };
-- 
2.47.3

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Fabio Estevam]

Hi Stefano,

On Tue, Feb 17, 2026 at 3:43 PM Stefano Radaelli
<stefano.radaelli21@gmail.com> wrote:
>
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Update the WiFi and Bluetooth configuration on the i.MX8MM VAR-SOM
> to match the latest SOM hardware revision.
>
> The SOM now integrates an NXP IW61x wireless module. WiFi is connected
> via SDIO and Bluetooth via UART.
>
> This patch:
> - Adds an mmc-pwrseq node to handle module reset and power sequencing.
> - Updates the USDHC1 node to use the new power sequence and required
>   pinctrl configuration.
> - Adds the Bluetooth child node under UART2.
> - Removes the legacy Broadcom WiFi device node.

What about users who still have boards with the Broadcom Wi-Fi chip?

Will Wifi on the old boards stop working?

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Stefano Radaelli]

Hi Fabio!

On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote:
> 
> What about users who still have boards with the Broadcom Wi-Fi chip?
> 
> Will Wifi on the old boards stop working?

The Broadcom-based WiFi module was used on earlier revisions of the
VAR-SOM-MX8MM. That hardware revision is no longer in production and
is not available for new orders. All currently manufactured and shipped
VAR-SOM-MX8MM modules integrate the NXP IW61x instead.

Since the wireless module is soldered on the SOM and not selectable via
the carrier board, the device tree must reflect the hardware that is
actually present on the module. This series aligns mainline with the
current production revision of the SOM.

Customers using older hardware revisions still have access to the
corresponding device tree descriptions in earlier kernel versions.
Upstream support is being aligned with the actively produced hardware.

The same applies to the Ethernet PHY update included in this series,
which reflects the PHY used on the current (and future) SOM revision.

Best regards,
Stefano

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Frank Li]

On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote:
> Hi Fabio!
>
> On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote:
> >
> > What about users who still have boards with the Broadcom Wi-Fi chip?
> >
> > Will Wifi on the old boards stop working?
>
> The Broadcom-based WiFi module was used on earlier revisions of the
> VAR-SOM-MX8MM. That hardware revision is no longer in production and
> is not available for new orders. All currently manufactured and shipped
> VAR-SOM-MX8MM modules integrate the NXP IW61x instead.

This common problem, we met similar case. After replace new compenent, it
should be new boards, or new revision.

I don't suggest directly replace it to broken old one. You can create dt
overlay files for new boards.

Krzysztof Kozlowski:
	how about other vendor handle similar case? Any guide line for
that?

Frank

>
> Since the wireless module is soldered on the SOM and not selectable via
> the carrier board, the device tree must reflect the hardware that is
> actually present on the module. This series aligns mainline with the
> current production revision of the SOM.
>
> Customers using older hardware revisions still have access to the
> corresponding device tree descriptions in earlier kernel versions.
> Upstream support is being aligned with the actively produced hardware.
>
> The same applies to the Ethernet PHY update included in this series,
> which reflects the PHY used on the current (and future) SOM revision.
>
> Best regards,
> Stefano

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Stefano Radaelli]

Hi Frank,

On Wed, Feb 18, 2026 at 11:35:23AM -0500, Frank Li wrote:
> On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote:
> > Hi Fabio!
> >
> > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote:
> > >
> > > What about users who still have boards with the Broadcom Wi-Fi chip?
> > >
> > > Will Wifi on the old boards stop working?
> >
> > The Broadcom-based WiFi module was used on earlier revisions of the
> > VAR-SOM-MX8MM. That hardware revision is no longer in production and
> > is not available for new orders. All currently manufactured and shipped
> > VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
> 
> This common problem, we met similar case. After replace new compenent, it
> should be new boards, or new revision.
> 
> I don't suggest directly replace it to broken old one. You can create dt
> overlay files for new boards.
> 
> Krzysztof Kozlowski:
> 	how about other vendor handle similar case? Any guide line for
> that?
> 
> Frank
> 

Thanks for the feedback!

We understand the concern about potential regressions on older SOM
revisions. However, since the wireless module is soldered on the SOM
and not configurable, we are aligning the upstream device tree with
the hardware revision that is currently in production.

This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM
platforms already present in mainline (e.g. i.MX8MP, i.MX93), which
use the IW61x wireless module as well. The intention is to keep the
VAR-SOM family consistent in mainline with the hardware that is
actively produced.

If there is a strong requirement to preserve an explicit description
of the older Broadcom-based revision in mainline, we can evaluate
adding a separate description.

Best regards,
Stefano

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Stefano Radaelli]

Hello everyone,

On Wed, Feb 18, 2026 at 06:18:16PM +0100, Stefano Radaelli wrote:
> Hi Frank,
> 
> On Wed, Feb 18, 2026 at 11:35:23AM -0500, Frank Li wrote:
> > On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote:
> > > Hi Fabio!
> > >
> > > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote:
> > > >
> > > > What about users who still have boards with the Broadcom Wi-Fi chip?
> > > >
> > > > Will Wifi on the old boards stop working?
> > >
> > > The Broadcom-based WiFi module was used on earlier revisions of the
> > > VAR-SOM-MX8MM. That hardware revision is no longer in production and
> > > is not available for new orders. All currently manufactured and shipped
> > > VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
> > 
> > This common problem, we met similar case. After replace new compenent, it
> > should be new boards, or new revision.
> > 
> > I don't suggest directly replace it to broken old one. You can create dt
> > overlay files for new boards.
> > 
> > Krzysztof Kozlowski:
> > 	how about other vendor handle similar case? Any guide line for
> > that?
> > 
> > Frank
> > 
> 
> Thanks for the feedback!
> 
> We understand the concern about potential regressions on older SOM
> revisions. However, since the wireless module is soldered on the SOM
> and not configurable, we are aligning the upstream device tree with
> the hardware revision that is currently in production.
> 
> This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM
> platforms already present in mainline (e.g. i.MX8MP, i.MX93), which
> use the IW61x wireless module as well. The intention is to keep the
> VAR-SOM family consistent in mainline with the hardware that is
> actively produced.
> 
> If there is a strong requirement to preserve an explicit description
> of the older Broadcom-based revision in mainline, we can evaluate
> adding a separate description.
> 
> Best regards,
> Stefano

Do you have any update about this topic?

Thank you a lot,
Best Regards,
Stefano

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Frank Li]

On Tue, Feb 24, 2026 at 03:57:10PM +0100, Stefano Radaelli wrote:
> Hello everyone,
>
> On Wed, Feb 18, 2026 at 06:18:16PM +0100, Stefano Radaelli wrote:
> > Hi Frank,
> >
> > On Wed, Feb 18, 2026 at 11:35:23AM -0500, Frank Li wrote:
> > > On Tue, Feb 17, 2026 at 08:42:19PM +0100, Stefano Radaelli wrote:
> > > > Hi Fabio!
> > > >
> > > > On Tue, Feb 17, 2026 at 03:59:33PM -0300, Fabio Estevam wrote:
> > > > >
> > > > > What about users who still have boards with the Broadcom Wi-Fi chip?
> > > > >
> > > > > Will Wifi on the old boards stop working?
> > > >
> > > > The Broadcom-based WiFi module was used on earlier revisions of the
> > > > VAR-SOM-MX8MM. That hardware revision is no longer in production and
> > > > is not available for new orders. All currently manufactured and shipped
> > > > VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
> > >
> > > This common problem, we met similar case. After replace new compenent, it
> > > should be new boards, or new revision.
> > >
> > > I don't suggest directly replace it to broken old one. You can create dt
> > > overlay files for new boards.
> > >
> > > Krzysztof Kozlowski:
> > > 	how about other vendor handle similar case? Any guide line for
> > > that?
> > >
> > > Frank
> > >
> >
> > Thanks for the feedback!
> >
> > We understand the concern about potential regressions on older SOM
> > revisions. However, since the wireless module is soldered on the SOM
> > and not configurable, we are aligning the upstream device tree with
> > the hardware revision that is currently in production.
> >
> > This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM
> > platforms already present in mainline (e.g. i.MX8MP, i.MX93), which
> > use the IW61x wireless module as well. The intention is to keep the
> > VAR-SOM family consistent in mainline with the hardware that is
> > actively produced.

Actually it becomes two boards. Change components is quite common. Direct
change at dts is not friendly for old boards users.

> >
> > If there is a strong requirement to preserve an explicit description
> > of the older Broadcom-based revision in mainline, we can evaluate
> > adding a separate description.
> >
> > Best regards,
> > Stefano
>
> Do you have any update about this topic?

If can't auto detected, I think keep old dts, use overlay change to new
one.

For example, board.dtb

you can rename board.dtb to board-revA.dtb
new board.dtb, by apply verb.dtso to board-revA.dtb.  Or you direct use
board-revb.dtb.

If change is big, you can create new one.

Frank
>
> Thank you a lot,
> Best Regards,
> Stefano

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Stefano Radaelli]

Hi Frank,

On Tue, Feb 24, 2026 at 04:30:28PM -0500, Frank Li wrote:
> 
> If can't auto detected, I think keep old dts, use overlay change to new
> one.
> 
> For example, board.dtb
> 
> you can rename board.dtb to board-revA.dtb
> new board.dtb, by apply verb.dtso to board-revA.dtb.  Or you direct use
> board-revb.dtb.
> 
> If change is big, you can create new one.
> 
> Frank

Thanks for the clarification, I understand that the preferred approach
would be to keep the existing Broadcom-based DTS unchanged and add a
separate description for the IW612-based revision.

My only concern is avoiding confusion in mainline.

The Broadcom-based SOM revision is obsolete and no longer manufactured.
All currently produced VAR-SOM-MX8MM modules use the IW612 module, and
this will remain the only production hardware going forward.

I would like to avoid giving the impression that we are actively
supporting two parallel SOM revisions in mainline, while in reality
only the IW612-based hardware exists in production.

For this reason, would it be acceptable to:

  - move the Broadcom-based description into an explicitly legacy
    revision-specific DTS (kept unchanged for existing users), and
  - update the main imx8mm-var-som DTS to reflect the current
    IW612-based hardware?

This would preserve compatibility for older boards, but ensure that
the primary DTS in mainline represents the hardware that is actually
produced and aligns with the rest of the VAR-SOM family.

Thank you again for your support and your patience!

Best regards,
Stefano

Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration

[Frank Li]

On Thu, Feb 26, 2026 at 06:44:59PM +0100, Stefano Radaelli wrote:
> Hi Frank,
>
> On Tue, Feb 24, 2026 at 04:30:28PM -0500, Frank Li wrote:
> >
> > If can't auto detected, I think keep old dts, use overlay change to new
> > one.
> >
> > For example, board.dtb
> >
> > you can rename board.dtb to board-revA.dtb
> > new board.dtb, by apply verb.dtso to board-revA.dtb.  Or you direct use
> > board-revb.dtb.
> >
> > If change is big, you can create new one.
> >
> > Frank
>
> Thanks for the clarification, I understand that the preferred approach
> would be to keep the existing Broadcom-based DTS unchanged and add a
> separate description for the IW612-based revision.
>
> My only concern is avoiding confusion in mainline.
>
> The Broadcom-based SOM revision is obsolete and no longer manufactured.
> All currently produced VAR-SOM-MX8MM modules use the IW612 module, and
> this will remain the only production hardware going forward.
>
> I would like to avoid giving the impression that we are actively
> supporting two parallel SOM revisions in mainline, while in reality
> only the IW612-based hardware exists in production.
>
> For this reason, would it be acceptable to:
>
>   - move the Broadcom-based description into an explicitly legacy
>     revision-specific DTS (kept unchanged for existing users), and
>   - update the main imx8mm-var-som DTS to reflect the current
>     IW612-based hardware?

The direction is correct. Just try to reduce duplicate the same code.

Frank


>
> This would preserve compatibility for older boards, but ensure that
> the primary DTS in mainline represents the hardware that is actually
> produced and aligns with the rest of the VAR-SOM family.
>
> Thank you again for your support and your patience!
>
> Best regards,
> Stefano

[PATCH v1 07/11] arm64: dts: imx8mm-var-som-symphony: Move USB configuration from SOM

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Move the USB controller configuration out of the i.MX8MM VAR-SOM dtsi
and into the VAR-SOM Symphony carrier board dts.

The SOM does not provide any USB connectors and carrier boards may
choose whether and how to route USB, therefore USB should be described
in the carrier-specific device tree instead of the SOM include.

While moving the nodes, align the Symphony USB description with the
carrier design by enabling both USB controllers, wiring USB1 to the
PTN5150 Type-C controller for dual-role operation, and updating the
PHY tuning and VBUS regulator pinctrl (including a sleep state).

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../dts/freescale/imx8mm-var-som-symphony.dts | 52 ++++++++++++-------
 .../boot/dts/freescale/imx8mm-var-som.dtsi    | 12 -----
 2 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 689894405b27..3242a0b739f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -30,6 +30,7 @@ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_reg_usb_otg2_vbus>;
+		pinctrl-1 = <&pinctrl_reg_usb_otg2_vbus_sleep>;
 		regulator-name = "usb_otg2_vbus";
 		regulator-min-microvolt = <5000000>;
 		regulator-max-microvolt = <5000000>;
@@ -117,13 +118,20 @@ enet-sel-hog {
 		};
 	};
 
-	extcon_usbotg1: typec@3d {
+	/* USB Type-C Controller */
+	ptn5150: typec@3d {
 		compatible = "nxp,ptn5150";
 		reg = <0x3d>;
-		interrupt-parent = <&gpio1>;
-		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_ptn5150>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <11 IRQ_TYPE_NONE>;
+
+		port {
+			typec1_dr_sw: endpoint {
+				remote-endpoint = <&usb1_drd_sw>;
+			};
+		};
 	};
 };
 
@@ -171,27 +179,29 @@ &uart4 {
 };
 
 &usbotg1 {
-	disable-over-current;
-	extcon = <&extcon_usbotg1>, <&extcon_usbotg1>;
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	samsung,picophy-dc-vol-level-adjust = <7>;
+	status = "okay";
+
+	port {
+		usb1_drd_sw: endpoint {
+			remote-endpoint = <&typec1_dr_sw>;
+		};
+	};
 };
 
 &usbotg2 {
 	dr_mode = "host";
 	vbus-supply = <&reg_usb_otg2_vbus>;
-	srp-disable;
-	hnp-disable;
-	adp-disable;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	samsung,picophy-dc-vol-level-adjust = <7>;
 	disable-over-current;
-	/delete-property/ usb-role-switch;
-	/*
-	 * FIXME: having USB2 enabled hangs the boot just after:
-	 * [    1.943365] ci_hdrc ci_hdrc.1: EHCI Host Controller
-	 * [    1.948287] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
-	 * [    1.971006] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
-	 * [    1.977203] hub 1-0:1.0: USB hub found
-	 * [    1.980987] hub 1-0:1.0: 1 port detected
-	 */
-	status = "disabled";
+	status = "okay";
 };
 
 &pinctrl_fec1 {
@@ -246,6 +256,12 @@ MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1		0x16
 		>;
 	};
 
+	pinctrl_reg_usb_otg2_vbus_sleep: regusbotg2vbus-sleepgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1		0x120
+		>;
+	};
+
 	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
 		fsl,pins = <
 			MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19	0x41
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index e2b1919d7188..96293036a4d4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -411,18 +411,6 @@ bluetooth_iw61x: bluetooth {
 	};
 };
 
-&usbotg1 {
-	dr_mode = "otg";
-	usb-role-switch;
-	status = "okay";
-};
-
-&usbotg2 {
-	dr_mode = "otg";
-	usb-role-switch;
-	status = "okay";
-};
-
 /* WIFI */
 &usdhc1 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz";
-- 
2.47.3

[PATCH v1 08/11] arm64: dts: imx8mm-var-som-symphony: Enable uSD on USDHC2

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Enable the microSD slot on the VAR-SOM Symphony carrier board.

Configure USDHC2 with card-detect GPIO, pinctrl states for the supported
bus speeds and the required VMMC supply.

Update the VMMC regulator to match the latest carrier revision by moving
the enable GPIO to GPIO4_IO22 and adding the required off-on delay.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../dts/freescale/imx8mm-var-som-symphony.dts | 59 ++++++++++++++++++-
 1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 3242a0b739f6..40ffa1f36b2f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -22,7 +22,8 @@ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
 		regulator-name = "VSD_3V3";
 		regulator-min-microvolt = <3300000>;
 		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+		off-on-delay-us = <20000>;
 		enable-active-high;
 	};
 
@@ -204,6 +205,18 @@ &usbotg2 {
 	status = "okay";
 };
 
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+	cd-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	status = "okay";
+};
+
 &pinctrl_fec1 {
 	fsl,pins = <
 		MX8MM_IOMUXC_ENET_MDC_ENET1_MDC			0x3
@@ -264,7 +277,7 @@ MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1		0x120
 
 	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
 		fsl,pins = <
-			MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19	0x41
+			MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22	0x41
 		>;
 	};
 
@@ -288,4 +301,46 @@ MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX	0x140
 			MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX	0x140
 		>;
 	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK		0x190
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD		0x1d0
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0	0x1d0
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1	0x1d0
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2	0x1d0
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3	0x1d0
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT	0x1d0
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK		0x194
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD		0x1d4
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0	0x1d4
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1	0x1d4
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2	0x1d4
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3	0x1d4
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT	0x1d0
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK		0x196
+			MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD		0x1d6
+			MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0	0x1d6
+			MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1	0x1d6
+			MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2	0x1d6
+			MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3	0x1d6
+			MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT	0x1d0
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10	0xc1
+		>;
+	};
 };
-- 
2.47.3

[PATCH v1 09/11] arm64: dts: imx8mm-var-som-symphony: Add TPM2 support

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Add support for the TPM2 device on the VAR-SOM Symphony carrier board.

The ST33K TPM2 is connected over I2C, and A PCA6408 GPIO expander is
used to control the reset signal required to release the TPM from reset.

This patch adds:
- The PCA6408 GPIO expander.
- The ST33K TPM2 device node.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../boot/dts/freescale/imx8mm-var-som-symphony.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 40ffa1f36b2f..b4dba1961eee 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -137,6 +137,20 @@ typec1_dr_sw: endpoint {
 };
 
 &i2c3 {
+	pca6408: gpio@21 {
+		compatible = "nxp,pcal6408";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+
+	st33ktpm2xi2c: tpm@2e {
+		compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+		reg = <0x2e>;
+		label = "tpm";
+		reset-gpios = <&pca6408 4 GPIO_ACTIVE_LOW>;
+	};
+
 	/* Capacitive touch controller */
 	ft5x06_ts: touchscreen@38 {
 		compatible = "edt,edt-ft5406";
-- 
2.47.3

[PATCH v1 10/11] arm64: dts: freescale: imx8mm-var-som-symphony: Enable I2C4

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Enable I2C4 on the Symphony carrier and add pinctrl configuration,
including GPIO-based bus recovery support.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../dts/freescale/imx8mm-var-som-symphony.dts | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index b4dba1961eee..3d9658edd58c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -172,6 +172,16 @@ rtc@68 {
 	};
 };
 
+&i2c4 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c4>;
+	pinctrl-1 = <&pinctrl_i2c4_gpio>;
+	scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+};
+
 /* Header */
 &uart1 {
 	pinctrl-names = "default";
@@ -265,6 +275,20 @@ MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA		0x400001c3
 		>;
 	};
 
+	pinctrl_i2c4: i2c4grp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL		0x400001c3
+			MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA		0x400001c3
+		>;
+	};
+
+	pinctrl_i2c4_gpio: i2c4gpiogrp {
+		fsl,pins = <
+			MX8MM_IOMUXC_I2C4_SCL_GPIO5_IO20	0x1c3
+			MX8MM_IOMUXC_I2C4_SDA_GPIO5_IO21	0x1c3
+		>;
+	};
+
 	pinctrl_pca9534: pca9534grp {
 		fsl,pins = <
 			MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7	0x16
-- 
2.47.3

[PATCH v1 11/11] arm64: dts: imx8mm-var-som-symphony: Enable PCIe

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Enable PCIe support on the VAR-SOM Symphony carrier board by adding the
external reference clock, configuring the PHY and providing the required
clock and reset properties.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../dts/freescale/imx8mm-var-som-symphony.dts | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 3d9658edd58c..8c1e2c77ba7f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/phy/phy-imx8-pcie.h>
 #include "imx8mm-var-som.dtsi"
 
 / {
@@ -15,6 +16,12 @@ chosen {
 		stdout-path = &uart4;
 	};
 
+	pcie0_refclk: pcie0-refclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <100000000>;
+	};
+
 	reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -182,6 +189,27 @@ &i2c4 {
 	status = "okay";
 };
 
+&pcie_phy {
+	fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+	fsl,tx-deemph-gen1 = <0x2d>;
+	fsl,tx-deemph-gen2 = <0xf>;
+	fsl,clkreq-unsupported;
+	clocks = <&pcie0_refclk>;
+	status = "okay";
+};
+
+&pcie0 {
+	reset-gpio = <&pca6408 1 GPIO_ACTIVE_LOW>;
+	clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&pcie0_refclk>,
+		 <&clk IMX8MM_CLK_PCIE1_AUX>;
+	assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+			  <&clk IMX8MM_CLK_PCIE1_CTRL>;
+	assigned-clock-rates = <10000000>, <250000000>;
+	assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+				 <&clk IMX8MM_SYS_PLL2_250M>;
+	status = "okay";
+};
+
 /* Header */
 &uart1 {
 	pinctrl-names = "default";
-- 
2.47.3