[PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant

[PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant

[Jan Kiszka]

This bring support for yet another IOT2050 device variant, see last
patch for details. The rest is binding and refactoring to make that
happen.

Jan

Baocheng Su (2):
  arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards
  dts: iot2050: Support IOT2050-SM variant

Jan Kiszka (1):
  arm64: dts: ti: iot2050: Factor out arduino connector bits

Su Bao Cheng (1):
  dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant

 .../devicetree/bindings/arm/ti/k3.yaml        |   1 +
 arch/arm64/boot/dts/ti/Makefile               |   1 +
 .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
 .../dts/ti/k3-am65-iot2050-common-pg2.dtsi    |   7 +-
 .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
 .../ti/k3-am6528-iot2050-basic-common.dtsi    |   6 +-
 .../boot/dts/ti/k3-am6528-iot2050-basic.dts   |   5 +
 .../dts/ti/k3-am6548-iot2050-advanced-m2.dts  |   6 +-
 .../dts/ti/k3-am6548-iot2050-advanced-pg2.dts |   8 +-
 .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 +++++
 .../dts/ti/k3-am6548-iot2050-advanced.dts     |   1 +
 11 files changed, 996 insertions(+), 770 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts

-- 
2.35.3

[PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant

[Jan Kiszka]

From: Su Bao Cheng <baocheng.su@siemens.com>

This new variant is derived from the Advanced PG2 board, removing the
Arduino interface, and adding a new ASIC for communicating with the
PLC 1200 signal modules.

Signed-off-by: Su Bao Cheng <baocheng.su@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 03d2a0d79fb0..2cb3f6eb8a43 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -91,6 +91,7 @@ properties:
               - siemens,iot2050-advanced
               - siemens,iot2050-advanced-m2
               - siemens,iot2050-advanced-pg2
+              - siemens,iot2050-advanced-sm
               - siemens,iot2050-basic
               - siemens,iot2050-basic-pg2
               - ti,am654-evm
-- 
2.35.3

[PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards

[Jan Kiszka]

From: Baocheng Su <baocheng.su@siemens.com>

The R5 lockstep disabling should be common for all PG2 boards, move it
from variants dts to common-pg2.dtsi.

As now the Basic PG2 consumes this twice, move Basic disabling to the
PG1 variant.

Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
[Jan: avoid duplication of disabling for Basic PG2]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi     | 7 ++++++-
 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi | 5 -----
 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts         | 5 +++++
 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts   | 5 -----
 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts  | 7 +------
 5 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi
index e9b57b87e42e..42adb8815f38 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) Siemens AG, 2021
+ * Copyright (c) Siemens AG, 2021-2023
  *
  * Authors:
  *   Chao Zeng <chao.zeng@siemens.com>
@@ -9,6 +9,11 @@
  * Common bits of the IOT2050 Basic and Advanced variants, PG2
  */
 
+&mcu_r5fss0 {
+	/* lock-step mode not supported on PG2 boards */
+	ti,cluster-mode = <0>;
+};
+
 &main_pmx0 {
 	cp2102n_reset_pin_default: cp2102n-reset-default-pins {
 		pinctrl-single,pins = <
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
index 5ab434c02ab6..2300abe69e94 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
@@ -54,8 +54,3 @@ &main_uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_uart0_pins_default>;
 };
-
-&mcu_r5fss0 {
-	/* lock-step mode not supported on Basic boards */
-	ti,cluster-mode = <0>;
-};
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
index 87928ff28214..be9c8db4c43a 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
@@ -22,3 +22,8 @@ / {
 	compatible = "siemens,iot2050-basic", "ti,am654";
 	model = "SIMATIC IOT2050 Basic";
 };
+
+&mcu_r5fss0 {
+	/* lock-step mode not supported on this board */
+	ti,cluster-mode = <0>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
index bd6f2e696e94..1e5d4d98b69b 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
@@ -21,11 +21,6 @@ / {
 	model = "SIMATIC IOT2050 Advanced M2";
 };
 
-&mcu_r5fss0 {
-	/* lock-step mode not supported on this board */
-	ti,cluster-mode = <0>;
-};
-
 &main_pmx0 {
 	main_bkey_pcie_reset: main-bkey-pcie-reset-default-pins {
 		pinctrl-single,pins = <
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
index f00dc86d01b9..a8ce8c891894 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) Siemens AG, 2018-2021
+ * Copyright (c) Siemens AG, 2018-2023
  *
  * Authors:
  *   Le Jin <le.jin@siemens.com>
@@ -22,8 +22,3 @@ / {
 	compatible = "siemens,iot2050-advanced-pg2", "ti,am654";
 	model = "SIMATIC IOT2050 Advanced PG2";
 };
-
-&mcu_r5fss0 {
-	/* lock-step mode not supported on this board */
-	ti,cluster-mode = <0>;
-};
-- 
2.35.3

[PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

A new variant is to be added which will not have a arduino connector
like the existing ones. Factor out all bits that are specific to this
connector.

The split is not perfect because wkup_gpio0 is defined based on what is
common to all variants having the connector, thus containing also
connector-unrelated information. But this is still cleaner than
replicating this node into all 4 variants.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
 .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
 .../ti/k3-am6528-iot2050-basic-common.dtsi    |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced-m2.dts  |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced-pg2.dts |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced.dts     |   1 +
 6 files changed, 772 insertions(+), 753 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
new file mode 100644
index 000000000000..cd86f412b837
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
@@ -0,0 +1,768 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2023
+ *
+ * Authors:
+ *   Le Jin <le.jin@siemens.com>
+ *   Jan Kiszka <jan.kiszka@siemens.com>
+ *
+ * Common bits for IOT2050 variants with Arduino connector
+ */
+
+&wkup_pmx0 {
+	pinctrl-names =
+		"default",
+		"d0-uart0-rxd",  "d0-gpio",  "d0-gpio-pullup",  "d0-gpio-pulldown",
+		"d1-uart0-txd",  "d1-gpio",  "d1-gpio-pullup",  "d1-gpio-pulldown",
+		"d2-uart0-ctsn", "d2-gpio",  "d2-gpio-pullup",  "d2-gpio-pulldown",
+		"d3-uart0-rtsn", "d3-gpio",  "d3-gpio-pullup",  "d3-gpio-pulldown",
+		"d10-spi0-cs0",  "d10-gpio", "d10-gpio-pullup", "d10-gpio-pulldown",
+		"d11-spi0-d0",   "d11-gpio", "d11-gpio-pullup", "d11-gpio-pulldown",
+		"d12-spi0-d1",   "d12-gpio", "d12-gpio-pullup", "d12-gpio-pulldown",
+		"d13-spi0-clk",  "d13-gpio", "d13-gpio-pullup", "d13-gpio-pulldown",
+		"a0-gpio", "a0-gpio-pullup", "a0-gpio-pulldown",
+		"a1-gpio", "a1-gpio-pullup", "a1-gpio-pulldown",
+		"a2-gpio", "a2-gpio-pullup", "a2-gpio-pulldown",
+		"a3-gpio", "a3-gpio-pullup", "a3-gpio-pulldown",
+		"a4-gpio", "a4-gpio-pullup", "a4-gpio-pulldown",
+		"a5-gpio", "a5-gpio-pullup", "a5-gpio-pulldown";
+
+	pinctrl-0 = <&d0_uart0_rxd>;
+	pinctrl-1 = <&d0_uart0_rxd>;
+	pinctrl-2 = <&d0_gpio>;
+	pinctrl-3 = <&d0_gpio_pullup>;
+	pinctrl-4 = <&d0_gpio_pulldown>;
+	pinctrl-5 = <&d1_uart0_txd>;
+	pinctrl-6 = <&d1_gpio>;
+	pinctrl-7 = <&d1_gpio_pullup>;
+	pinctrl-8 = <&d1_gpio_pulldown>;
+	pinctrl-9 = <&d2_uart0_ctsn>;
+	pinctrl-10 = <&d2_gpio>;
+	pinctrl-11 = <&d2_gpio_pullup>;
+	pinctrl-12 = <&d2_gpio_pulldown>;
+	pinctrl-13 = <&d3_uart0_rtsn>;
+	pinctrl-14 = <&d3_gpio>;
+	pinctrl-15 = <&d3_gpio_pullup>;
+	pinctrl-16 = <&d3_gpio_pulldown>;
+	pinctrl-17 = <&d10_spi0_cs0>;
+	pinctrl-18 = <&d10_gpio>;
+	pinctrl-19 = <&d10_gpio_pullup>;
+	pinctrl-20 = <&d10_gpio_pulldown>;
+	pinctrl-21 = <&d11_spi0_d0>;
+	pinctrl-22 = <&d11_gpio>;
+	pinctrl-23 = <&d11_gpio_pullup>;
+	pinctrl-24 = <&d11_gpio_pulldown>;
+	pinctrl-25 = <&d12_spi0_d1>;
+	pinctrl-26 = <&d12_gpio>;
+	pinctrl-27 = <&d12_gpio_pullup>;
+	pinctrl-28 = <&d12_gpio_pulldown>;
+	pinctrl-29 = <&d13_spi0_clk>;
+	pinctrl-30 = <&d13_gpio>;
+	pinctrl-31 = <&d13_gpio_pullup>;
+	pinctrl-32 = <&d13_gpio_pulldown>;
+	pinctrl-33 = <&a0_gpio>;
+	pinctrl-34 = <&a0_gpio_pullup>;
+	pinctrl-35 = <&a0_gpio_pulldown>;
+	pinctrl-36 = <&a1_gpio>;
+	pinctrl-37 = <&a1_gpio_pullup>;
+	pinctrl-38 = <&a1_gpio_pulldown>;
+	pinctrl-39 = <&a2_gpio>;
+	pinctrl-40 = <&a2_gpio_pullup>;
+	pinctrl-41 = <&a2_gpio_pulldown>;
+	pinctrl-42 = <&a3_gpio>;
+	pinctrl-43 = <&a3_gpio_pullup>;
+	pinctrl-44 = <&a3_gpio_pulldown>;
+	pinctrl-45 = <&a4_gpio>;
+	pinctrl-46 = <&a4_gpio_pullup>;
+	pinctrl-47 = <&a4_gpio_pulldown>;
+	pinctrl-48 = <&a5_gpio>;
+	pinctrl-49 = <&a5_gpio_pullup>;
+	pinctrl-50 = <&a5_gpio_pulldown>;
+
+	d0_uart0_rxd: d0-uart0-rxd-pins {
+		pinctrl-single,pins = <
+			/* (P4) MCU_UART0_RXD */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
+		>;
+	};
+
+	d0_gpio: d0-gpio-pins {
+		pinctrl-single,pins = <
+			/* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7)
+		>;
+	};
+
+	d0_gpio_pullup: d0-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d0_gpio_pulldown: d0-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d1_uart0_txd: d1-uart0-txd-pins {
+		pinctrl-single,pins = <
+			/* (P5) MCU_UART0_TXD */
+			AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4)
+		>;
+	};
+
+	d1_gpio: d1-gpio-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
+		>;
+	};
+
+	d1_gpio_pullup: d1-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
+		>;
+	};
+
+	d1_gpio_pulldown: d1-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d2_uart0_ctsn: d2-uart0-ctsn-pins {
+		pinctrl-single,pins = <
+			/* (P1) MCU_UART0_CTSn */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4)
+		>;
+	};
+
+	d2_gpio: d2-gpio-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_31 */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
+		>;
+	};
+
+	d2_gpio_pullup: d2-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_31 */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
+		>;
+	};
+
+	d2_gpio_pulldown: d2-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (P5) WKUP_GPIO0_31 */
+			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d3_uart0_rtsn: d3-uart0-rtsn-pins {
+		pinctrl-single,pins = <
+			/* (N3) MCU_UART0_RTSn */
+			AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4)
+		>;
+	};
+
+	d3_gpio: d3-gpio-pins {
+		pinctrl-single,pins = <
+			/* (N3) WKUP_GPIO0_33 */
+			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
+		>;
+	};
+
+	d3_gpio_pullup: d3-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (N3) WKUP_GPIO0_33 */
+			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
+		>;
+	};
+
+	d3_gpio_pulldown: d3-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (N3) WKUP_GPIO0_33 */
+			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d10_spi0_cs0: d10-spi0-cs0-pins {
+		pinctrl-single,pins = <
+			/* (Y4) MCU_SPI0_CS0 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0)
+		>;
+	};
+
+	d10_gpio: d10-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y4) WKUP_GPIO0_51 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
+		>;
+	};
+
+	d10_gpio_pullup: d10-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y4) WKUP_GPIO0_51 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
+		>;
+	};
+
+	d10_gpio_pulldown: d10-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y4) WKUP_GPIO0_51 */
+			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d11_spi0_d0: d11-spi0-d0-pins {
+		pinctrl-single,pins = <
+			/* (Y3) MCU_SPI0_D0 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0)
+		>;
+	};
+
+	d11_gpio: d11-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y3) WKUP_GPIO0_49 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
+		>;
+	};
+
+	d11_gpio_pullup: d11-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y3) WKUP_GPIO0_49 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
+		>;
+	};
+
+	d11_gpio_pulldown: d11-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y3) WKUP_GPIO0_49 */
+			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d12_spi0_d1: d12-spi0-d1-pins {
+		pinctrl-single,pins = <
+			/* (Y2) MCU_SPI0_D1 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0)
+		>;
+	};
+
+	d12_gpio: d12-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y2) WKUP_GPIO0_50 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
+		>;
+	};
+
+	d12_gpio_pullup: d12-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y2) WKUP_GPIO0_50 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
+		>;
+	};
+
+	d12_gpio_pulldown: d12-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y2) WKUP_GPIO0_50 */
+			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d13_spi0_clk: d13-spi0-clk-pins {
+		pinctrl-single,pins = <
+			/* (Y1) MCU_SPI0_CLK */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0)
+		>;
+	};
+
+	d13_gpio: d13-gpio-pins {
+		pinctrl-single,pins = <
+			/* (Y1) WKUP_GPIO0_48 */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
+		>;
+	};
+
+	d13_gpio_pullup: d13-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (Y1) WKUP_GPIO0_48 */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
+		>;
+	};
+
+	d13_gpio_pulldown: d13-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (Y1) WKUP_GPIO0_48 */
+			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a0_gpio: a0-gpio-pins {
+		pinctrl-single,pins = <
+			/* (L6) WKUP_GPIO0_45 */
+			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
+		>;
+	};
+
+	a0_gpio_pullup: a0-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (L6) WKUP_GPIO0_45 */
+			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
+		>;
+	};
+
+	a0_gpio_pulldown: a0-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (L6) WKUP_GPIO0_45 */
+			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a1_gpio: a1-gpio-pins {
+		pinctrl-single,pins = <
+			/* (M6) WKUP_GPIO0_44 */
+			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
+		>;
+	};
+
+	a1_gpio_pullup: a1-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (M6) WKUP_GPIO0_44 */
+			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
+		>;
+	};
+
+	a1_gpio_pulldown: a1-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (M6) WKUP_GPIO0_44 */
+			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a2_gpio: a2-gpio-pins {
+		pinctrl-single,pins = <
+			/* (L5) WKUP_GPIO0_43 */
+			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
+		>;
+	};
+
+	a2_gpio_pullup: a2-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (L5) WKUP_GPIO0_43 */
+			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
+		>;
+	};
+
+	a2_gpio_pulldown: a2-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (L5) WKUP_GPIO0_43 */
+			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a3_gpio: a3-gpio-pins {
+		pinctrl-single,pins = <
+			/* (M5) WKUP_GPIO0_39 */
+			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
+		>;
+	};
+
+	a3_gpio_pullup: a3-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (M5) WKUP_GPIO0_39 */
+			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
+		>;
+	};
+
+	a3_gpio_pulldown: a3-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (M5) WKUP_GPIO0_39 */
+			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a4_gpio: a4-gpio-pins {
+		pinctrl-single,pins = <
+			/* (L2) WKUP_GPIO0_42 */
+			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
+		>;
+	};
+
+	a4_gpio_pullup: a4-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (L2) WKUP_GPIO0_42 */
+			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
+		>;
+	};
+
+	a4_gpio_pulldown: a4-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (L2) WKUP_GPIO0_42 */
+			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	a5_gpio: a5-gpio-pins {
+		pinctrl-single,pins = <
+			/* (N5) WKUP_GPIO0_35 */
+			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT, 7)
+		>;
+	};
+
+	a5_gpio_pullup: a5-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (N5) WKUP_GPIO0_35 */
+			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	a5_gpio_pulldown: a5-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (N5) WKUP_GPIO0_35 */
+			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+		pinctrl-single,pins = <
+			/* (AC7) WKUP_I2C0_SCL */
+			AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT,  0)
+			/* (AD6) WKUP_I2C0_SDA */
+			AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT,  0)
+		>;
+	};
+
+	arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins {
+		pinctrl-single,pins = <
+			/* (R2) WKUP_GPIO0_21 */
+			AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
+		>;
+	};
+
+	arduino_io_oe_pins_default: arduino-io-oe-default-pins {
+		pinctrl-single,pins = <
+			/* (N4) WKUP_GPIO0_34 */
+			AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7)
+			/* (M2) WKUP_GPIO0_36 */
+			AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7)
+			/* (M3) WKUP_GPIO0_37 */
+			AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7)
+			/* (M4) WKUP_GPIO0_38 */
+			AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7)
+			/* (M1) WKUP_GPIO0_41 */
+			AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7)
+		>;
+	};
+};
+
+&main_pmx0 {
+	pinctrl-names =
+		"default",
+		"d4-ehrpwm0-a", "d4-gpio", "d4-gpio-pullup", "d4-gpio-pulldown",
+		"d5-ehrpwm1-a", "d5-gpio", "d5-gpio-pullup", "d5-gpio-pulldown",
+		"d6-ehrpwm2-a", "d6-gpio", "d6-gpio-pullup", "d6-gpio-pulldown",
+		"d7-ehrpwm3-a", "d7-gpio", "d7-gpio-pullup", "d7-gpio-pulldown",
+		"d8-ehrpwm4-a", "d8-gpio", "d8-gpio-pullup", "d8-gpio-pulldown",
+		"d9-ehrpwm5-a", "d9-gpio", "d9-gpio-pullup", "d9-gpio-pulldown";
+
+	pinctrl-0 = <&d4_ehrpwm0_a>;
+	pinctrl-1 = <&d4_ehrpwm0_a>;
+	pinctrl-2 = <&d4_gpio>;
+	pinctrl-3 = <&d4_gpio_pullup>;
+	pinctrl-4 = <&d4_gpio_pulldown>;
+
+	pinctrl-5 = <&d5_ehrpwm1_a>;
+	pinctrl-6 = <&d5_gpio>;
+	pinctrl-7 = <&d5_gpio_pullup>;
+	pinctrl-8 = <&d5_gpio_pulldown>;
+
+	pinctrl-9 = <&d6_ehrpwm2_a>;
+	pinctrl-10 = <&d6_gpio>;
+	pinctrl-11 = <&d6_gpio_pullup>;
+	pinctrl-12 = <&d6_gpio_pulldown>;
+
+	pinctrl-13 = <&d7_ehrpwm3_a>;
+	pinctrl-14 = <&d7_gpio>;
+	pinctrl-15 = <&d7_gpio_pullup>;
+	pinctrl-16 = <&d7_gpio_pulldown>;
+
+	pinctrl-17 = <&d8_ehrpwm4_a>;
+	pinctrl-18 = <&d8_gpio>;
+	pinctrl-19 = <&d8_gpio_pullup>;
+	pinctrl-20 = <&d8_gpio_pulldown>;
+
+	pinctrl-21 = <&d9_ehrpwm5_a>;
+	pinctrl-22 = <&d9_gpio>;
+	pinctrl-23 = <&d9_gpio_pullup>;
+	pinctrl-24 = <&d9_gpio_pulldown>;
+
+	d4_ehrpwm0_a: d4-ehrpwm0-a-pins {
+		pinctrl-single,pins = <
+			/* (AG18) EHRPWM0_A */
+			AM65X_IOPAD(0x0084, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d4_gpio: d4-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AG18) GPIO0_33 */
+			AM65X_IOPAD(0x0084, PIN_INPUT, 7)
+		>;
+	};
+
+	d4_gpio_pullup: d4-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AG18) GPIO0_33 */
+			AM65X_IOPAD(0x0084, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d4_gpio_pulldown: d4-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AG18) GPIO0_33 */
+			AM65X_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d5_ehrpwm1_a: d5-ehrpwm1-a-pins {
+		pinctrl-single,pins = <
+			/* (AF17) EHRPWM1_A */
+			AM65X_IOPAD(0x008C, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d5_gpio: d5-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AF17) GPIO0_35 */
+			AM65X_IOPAD(0x008C, PIN_INPUT, 7)
+		>;
+	};
+
+	d5_gpio_pullup: d5-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AF17) GPIO0_35 */
+			AM65X_IOPAD(0x008C, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d5_gpio_pulldown: d5-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AF17) GPIO0_35 */
+			AM65X_IOPAD(0x008C, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d6_ehrpwm2_a: d6-ehrpwm2-a-pins {
+		pinctrl-single,pins = <
+			/* (AH16) EHRPWM2_A */
+			AM65X_IOPAD(0x0098, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d6_gpio: d6-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AH16) GPIO0_38 */
+			AM65X_IOPAD(0x0098, PIN_INPUT, 7)
+		>;
+	};
+
+	d6_gpio_pullup: d6-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AH16) GPIO0_38 */
+			AM65X_IOPAD(0x0098, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d6_gpio_pulldown: d6-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AH16) GPIO0_38 */
+			AM65X_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d7_ehrpwm3_a: d7-ehrpwm3-a-pins {
+		pinctrl-single,pins = <
+			/* (AH15) EHRPWM3_A */
+			AM65X_IOPAD(0x00AC, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d7_gpio: d7-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AH15) GPIO0_43 */
+			AM65X_IOPAD(0x00AC, PIN_INPUT, 7)
+		>;
+	};
+
+	d7_gpio_pullup: d7-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AH15) GPIO0_43 */
+			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d7_gpio_pulldown: d7-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AH15) GPIO0_43 */
+			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d8_ehrpwm4_a: d8-ehrpwm4-a-pins {
+		pinctrl-single,pins = <
+			/* (AG15) EHRPWM4_A */
+			AM65X_IOPAD(0x00C0, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d8_gpio: d8-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AG15) GPIO0_48 */
+			AM65X_IOPAD(0x00C0, PIN_INPUT, 7)
+		>;
+	};
+
+	d8_gpio_pullup: d8-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AG15) GPIO0_48 */
+			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d8_gpio_pulldown: d8-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AG15) GPIO0_48 */
+			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+
+	d9_ehrpwm5_a: d9-ehrpwm5-a-pins {
+		pinctrl-single,pins = <
+			/* (AD15) EHRPWM5_A */
+			AM65X_IOPAD(0x00CC, PIN_OUTPUT, 5)
+		>;
+	};
+
+	d9_gpio: d9-gpio-pins {
+		pinctrl-single,pins = <
+			/* (AD15) GPIO0_51 */
+			AM65X_IOPAD(0x00CC, PIN_INPUT, 7)
+		>;
+	};
+
+	d9_gpio_pullup: d9-gpio-pullup-pins {
+		pinctrl-single,pins = <
+			/* (AD15) GPIO0_51 */
+			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLUP, 7)
+		>;
+	};
+
+	d9_gpio_pulldown: d9-gpio-pulldown-pins {
+		pinctrl-single,pins = <
+			/* (AD15) GPIO0_51 */
+			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLDOWN, 7)
+		>;
+	};
+};
+
+&main_gpio0 {
+	gpio-line-names =
+		"main_gpio0-base", "", "", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "", "", "",
+		"", "", "", "IO4", "", "IO5", "", "", "IO6", "",
+		"", "", "", "IO7", "", "", "", "", "IO8", "",
+		"", "IO9";
+};
+
+&wkup_gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 =
+		<&arduino_i2c_aio_switch_pins_default>,
+		<&arduino_io_oe_pins_default>,
+		<&push_button_pins_default>,
+		<&db9_com_mode_pins_default>;
+	gpio-line-names =
+		/* 0..9 */
+		"wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0",
+		"UART0-enable", "UART0-terminate", "", "WIFI-disable",
+		/* 10..19 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 20..29 */
+		"", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0",
+		/* 30..39 */
+		"IO1", "IO2", "", "IO3", "IO17-direction", "A5",
+		"IO16-direction", "IO15-direction", "IO14-direction", "A3",
+		/* 40..49 */
+		"", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13",
+		"IO11",
+		/* 50..51 */
+		"IO12", "IO10";
+};
+
+&wkup_i2c0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&wkup_i2c0_pins_default>;
+	clock-frequency = <400000>;
+};
+
+&mcu_i2c0 {
+	/* D4200 */
+	pcal9535_1: gpio@20 {
+		compatible = "nxp,pcal9535";
+		reg = <0x20>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-line-names =
+			"A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
+			"A5-pull", "", "",
+			"IO14-enable", "IO15-enable", "IO16-enable",
+			"IO17-enable", "IO18-enable", "IO19-enable";
+	};
+
+	/* D4201 */
+	pcal9535_2: gpio@21 {
+		compatible = "nxp,pcal9535";
+		reg = <0x21>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-line-names =
+			"IO0-direction", "IO1-direction", "IO2-direction",
+			"IO3-direction", "IO4-direction", "IO5-direction",
+			"IO6-direction", "IO7-direction",
+			"IO8-direction", "IO9-direction", "IO10-direction",
+			"IO11-direction", "IO12-direction", "IO13-direction",
+			"IO19-direction";
+	};
+
+	/* D4202 */
+	pcal9535_3: gpio@25 {
+		compatible = "nxp,pcal9535";
+		reg = <0x25>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-line-names =
+			"IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
+			"IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
+			"IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
+			"IO12-pull", "IO13-pull";
+	};
+};
+
+&mcu_uart0 {
+	status = "okay";
+};
+
+&tscadc1 {
+	status = "okay";
+	adc {
+		ti,adc-channels = <0 1 2 3 4 5>;
+	};
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
index ab1dffa5c1c6..402afa4bc1b6 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -187,434 +187,6 @@ icssg0_emac1: port@1 {
 };
 
 &wkup_pmx0 {
-	pinctrl-names =
-		"default",
-		"d0-uart0-rxd",  "d0-gpio",  "d0-gpio-pullup",  "d0-gpio-pulldown",
-		"d1-uart0-txd",  "d1-gpio",  "d1-gpio-pullup",  "d1-gpio-pulldown",
-		"d2-uart0-ctsn", "d2-gpio",  "d2-gpio-pullup",  "d2-gpio-pulldown",
-		"d3-uart0-rtsn", "d3-gpio",  "d3-gpio-pullup",  "d3-gpio-pulldown",
-		"d10-spi0-cs0",  "d10-gpio", "d10-gpio-pullup", "d10-gpio-pulldown",
-		"d11-spi0-d0",   "d11-gpio", "d11-gpio-pullup", "d11-gpio-pulldown",
-		"d12-spi0-d1",   "d12-gpio", "d12-gpio-pullup", "d12-gpio-pulldown",
-		"d13-spi0-clk",  "d13-gpio", "d13-gpio-pullup", "d13-gpio-pulldown",
-		"a0-gpio", "a0-gpio-pullup", "a0-gpio-pulldown",
-		"a1-gpio", "a1-gpio-pullup", "a1-gpio-pulldown",
-		"a2-gpio", "a2-gpio-pullup", "a2-gpio-pulldown",
-		"a3-gpio", "a3-gpio-pullup", "a3-gpio-pulldown",
-		"a4-gpio", "a4-gpio-pullup", "a4-gpio-pulldown",
-		"a5-gpio", "a5-gpio-pullup", "a5-gpio-pulldown";
-
-	pinctrl-0 = <&d0_uart0_rxd>;
-	pinctrl-1 = <&d0_uart0_rxd>;
-	pinctrl-2 = <&d0_gpio>;
-	pinctrl-3 = <&d0_gpio_pullup>;
-	pinctrl-4 = <&d0_gpio_pulldown>;
-	pinctrl-5 = <&d1_uart0_txd>;
-	pinctrl-6 = <&d1_gpio>;
-	pinctrl-7 = <&d1_gpio_pullup>;
-	pinctrl-8 = <&d1_gpio_pulldown>;
-	pinctrl-9 = <&d2_uart0_ctsn>;
-	pinctrl-10 = <&d2_gpio>;
-	pinctrl-11 = <&d2_gpio_pullup>;
-	pinctrl-12 = <&d2_gpio_pulldown>;
-	pinctrl-13 = <&d3_uart0_rtsn>;
-	pinctrl-14 = <&d3_gpio>;
-	pinctrl-15 = <&d3_gpio_pullup>;
-	pinctrl-16 = <&d3_gpio_pulldown>;
-	pinctrl-17 = <&d10_spi0_cs0>;
-	pinctrl-18 = <&d10_gpio>;
-	pinctrl-19 = <&d10_gpio_pullup>;
-	pinctrl-20 = <&d10_gpio_pulldown>;
-	pinctrl-21 = <&d11_spi0_d0>;
-	pinctrl-22 = <&d11_gpio>;
-	pinctrl-23 = <&d11_gpio_pullup>;
-	pinctrl-24 = <&d11_gpio_pulldown>;
-	pinctrl-25 = <&d12_spi0_d1>;
-	pinctrl-26 = <&d12_gpio>;
-	pinctrl-27 = <&d12_gpio_pullup>;
-	pinctrl-28 = <&d12_gpio_pulldown>;
-	pinctrl-29 = <&d13_spi0_clk>;
-	pinctrl-30 = <&d13_gpio>;
-	pinctrl-31 = <&d13_gpio_pullup>;
-	pinctrl-32 = <&d13_gpio_pulldown>;
-	pinctrl-33 = <&a0_gpio>;
-	pinctrl-34 = <&a0_gpio_pullup>;
-	pinctrl-35 = <&a0_gpio_pulldown>;
-	pinctrl-36 = <&a1_gpio>;
-	pinctrl-37 = <&a1_gpio_pullup>;
-	pinctrl-38 = <&a1_gpio_pulldown>;
-	pinctrl-39 = <&a2_gpio>;
-	pinctrl-40 = <&a2_gpio_pullup>;
-	pinctrl-41 = <&a2_gpio_pulldown>;
-	pinctrl-42 = <&a3_gpio>;
-	pinctrl-43 = <&a3_gpio_pullup>;
-	pinctrl-44 = <&a3_gpio_pulldown>;
-	pinctrl-45 = <&a4_gpio>;
-	pinctrl-46 = <&a4_gpio_pullup>;
-	pinctrl-47 = <&a4_gpio_pulldown>;
-	pinctrl-48 = <&a5_gpio>;
-	pinctrl-49 = <&a5_gpio_pullup>;
-	pinctrl-50 = <&a5_gpio_pulldown>;
-
-	d0_uart0_rxd: d0-uart0-rxd-pins {
-		pinctrl-single,pins = <
-			/* (P4) MCU_UART0_RXD */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
-		>;
-	};
-
-	d0_gpio: d0-gpio-pins {
-		pinctrl-single,pins = <
-			/* (P4) WKUP_GPIO0_29 */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7)
-		>;
-	};
-
-	d0_gpio_pullup: d0-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (P4) WKUP_GPIO0_29 */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d0_gpio_pulldown: d0-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (P4) WKUP_GPIO0_29 */
-			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d1_uart0_txd: d1-uart0-txd-pins {
-		pinctrl-single,pins = <
-			/* (P5) MCU_UART0_TXD */
-			AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4)
-		>;
-	};
-
-	d1_gpio: d1-gpio-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_30 */
-			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
-		>;
-	};
-
-	d1_gpio_pullup: d1-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_30 */
-			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)
-		>;
-	};
-
-	d1_gpio_pulldown: d1-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_30 */
-			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d2_uart0_ctsn: d2-uart0-ctsn-pins {
-		pinctrl-single,pins = <
-			/* (P1) MCU_UART0_CTSn */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4)
-		>;
-	};
-
-	d2_gpio: d2-gpio-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_31 */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
-		>;
-	};
-
-	d2_gpio_pullup: d2-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_31 */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7)
-		>;
-	};
-
-	d2_gpio_pulldown: d2-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (P5) WKUP_GPIO0_31 */
-			AM65X_WKUP_IOPAD(0x004C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d3_uart0_rtsn: d3-uart0-rtsn-pins {
-		pinctrl-single,pins = <
-			/* (N3) MCU_UART0_RTSn */
-			AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4)
-		>;
-	};
-
-	d3_gpio: d3-gpio-pins {
-		pinctrl-single,pins = <
-			/* (N3) WKUP_GPIO0_33 */
-			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
-		>;
-	};
-
-	d3_gpio_pullup: d3-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (N3) WKUP_GPIO0_33 */
-			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7)
-		>;
-	};
-
-	d3_gpio_pulldown: d3-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (N3) WKUP_GPIO0_33 */
-			AM65X_WKUP_IOPAD(0x0054, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d10_spi0_cs0: d10-spi0-cs0-pins {
-		pinctrl-single,pins = <
-			/* (Y4) MCU_SPI0_CS0 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0)
-		>;
-	};
-
-	d10_gpio: d10-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y4) WKUP_GPIO0_51 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
-		>;
-	};
-
-	d10_gpio_pullup: d10-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y4) WKUP_GPIO0_51 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7)
-		>;
-	};
-
-	d10_gpio_pulldown: d10-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y4) WKUP_GPIO0_51 */
-			AM65X_WKUP_IOPAD(0x009c, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d11_spi0_d0: d11-spi0-d0-pins {
-		pinctrl-single,pins = <
-			/* (Y3) MCU_SPI0_D0 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0)
-		>;
-	};
-
-	d11_gpio: d11-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y3) WKUP_GPIO0_49 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
-		>;
-	};
-
-	d11_gpio_pullup: d11-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y3) WKUP_GPIO0_49 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7)
-		>;
-	};
-
-	d11_gpio_pulldown: d11-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y3) WKUP_GPIO0_49 */
-			AM65X_WKUP_IOPAD(0x0094, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d12_spi0_d1: d12-spi0-d1-pins {
-		pinctrl-single,pins = <
-			/* (Y2) MCU_SPI0_D1 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0)
-		>;
-	};
-
-	d12_gpio: d12-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y2) WKUP_GPIO0_50 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
-		>;
-	};
-
-	d12_gpio_pullup: d12-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y2) WKUP_GPIO0_50 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7)
-		>;
-	};
-
-	d12_gpio_pulldown: d12-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y2) WKUP_GPIO0_50 */
-			AM65X_WKUP_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d13_spi0_clk: d13-spi0-clk-pins {
-		pinctrl-single,pins = <
-			/* (Y1) MCU_SPI0_CLK */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0)
-		>;
-	};
-
-	d13_gpio: d13-gpio-pins {
-		pinctrl-single,pins = <
-			/* (Y1) WKUP_GPIO0_48 */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
-		>;
-	};
-
-	d13_gpio_pullup: d13-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (Y1) WKUP_GPIO0_48 */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7)
-		>;
-	};
-
-	d13_gpio_pulldown: d13-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (Y1) WKUP_GPIO0_48 */
-			AM65X_WKUP_IOPAD(0x0090, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a0_gpio: a0-gpio-pins {
-		pinctrl-single,pins = <
-			/* (L6) WKUP_GPIO0_45 */
-			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
-		>;
-	};
-
-	a0_gpio_pullup: a0-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (L6) WKUP_GPIO0_45 */
-			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7)
-		>;
-	};
-
-	a0_gpio_pulldown: a0-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (L6) WKUP_GPIO0_45 */
-			AM65X_WKUP_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a1_gpio: a1-gpio-pins {
-		pinctrl-single,pins = <
-			/* (M6) WKUP_GPIO0_44 */
-			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
-		>;
-	};
-
-	a1_gpio_pullup: a1-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (M6) WKUP_GPIO0_44 */
-			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7)
-		>;
-	};
-
-	a1_gpio_pulldown: a1-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (M6) WKUP_GPIO0_44 */
-			AM65X_WKUP_IOPAD(0x0080, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a2_gpio: a2-gpio-pins {
-		pinctrl-single,pins = <
-			/* (L5) WKUP_GPIO0_43 */
-			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
-		>;
-	};
-
-	a2_gpio_pullup: a2-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (L5) WKUP_GPIO0_43 */
-			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7)
-		>;
-	};
-
-	a2_gpio_pulldown: a2-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (L5) WKUP_GPIO0_43 */
-			AM65X_WKUP_IOPAD(0x007C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a3_gpio: a3-gpio-pins {
-		pinctrl-single,pins = <
-			/* (M5) WKUP_GPIO0_39 */
-			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
-		>;
-	};
-
-	a3_gpio_pullup: a3-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (M5) WKUP_GPIO0_39 */
-			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7)
-		>;
-	};
-
-	a3_gpio_pulldown: a3-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (M5) WKUP_GPIO0_39 */
-			AM65X_WKUP_IOPAD(0x006C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a4_gpio: a4-gpio-pins {
-		pinctrl-single,pins = <
-			/* (L2) WKUP_GPIO0_42 */
-			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
-		>;
-	};
-
-	a4_gpio_pullup: a4-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (L2) WKUP_GPIO0_42 */
-			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7)
-		>;
-	};
-
-	a4_gpio_pulldown: a4-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (L2) WKUP_GPIO0_42 */
-			AM65X_WKUP_IOPAD(0x0078, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	a5_gpio: a5-gpio-pins {
-		pinctrl-single,pins = <
-			/* (N5) WKUP_GPIO0_35 */
-			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT, 7)
-		>;
-	};
-
-	a5_gpio_pullup: a5-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (N5) WKUP_GPIO0_35 */
-			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	a5_gpio_pulldown: a5-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (N5) WKUP_GPIO0_35 */
-			AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	wkup_i2c0_pins_default: wkup-i2c0-default-pins {
-		pinctrl-single,pins = <
-			/* (AC7) WKUP_I2C0_SCL */
-			AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT,  0)
-			/* (AD6) WKUP_I2C0_SDA */
-			AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT,  0)
-		>;
-	};
-
 	mcu_i2c0_pins_default: mcu-i2c0-default-pins {
 		pinctrl-single,pins = <
 			/* (AD8) MCU_I2C0_SCL */
@@ -624,13 +196,6 @@ AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT,  0)
 		>;
 	};
 
-	arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins {
-		pinctrl-single,pins = <
-			/* (R2) WKUP_GPIO0_21 */
-			AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
-		>;
-	};
-
 	push_button_pins_default: push-button-default-pins {
 		pinctrl-single,pins = <
 			/* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
@@ -638,22 +203,6 @@ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT,  7)
 		>;
 	};
 
-
-	arduino_io_oe_pins_default: arduino-io-oe-default-pins {
-		pinctrl-single,pins = <
-			/* (N4) WKUP_GPIO0_34 */
-			AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7)
-			/* (M2) WKUP_GPIO0_36 */
-			AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7)
-			/* (M3) WKUP_GPIO0_37 */
-			AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7)
-			/* (M4) WKUP_GPIO0_38 */
-			AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7)
-			/* (M1) WKUP_GPIO0_41 */
-			AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7)
-		>;
-	};
-
 	mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
 		pinctrl-single,pins = <
 			/* (V1) MCU_OSPI0_CLK */
@@ -717,214 +266,6 @@ AM65X_WKUP_IOPAD(0x003C, PIN_OUTPUT, 7)
 };
 
 &main_pmx0 {
-	pinctrl-names =
-		"default",
-		"d4-ehrpwm0-a", "d4-gpio", "d4-gpio-pullup", "d4-gpio-pulldown",
-		"d5-ehrpwm1-a", "d5-gpio", "d5-gpio-pullup", "d5-gpio-pulldown",
-		"d6-ehrpwm2-a", "d6-gpio", "d6-gpio-pullup", "d6-gpio-pulldown",
-		"d7-ehrpwm3-a", "d7-gpio", "d7-gpio-pullup", "d7-gpio-pulldown",
-		"d8-ehrpwm4-a", "d8-gpio", "d8-gpio-pullup", "d8-gpio-pulldown",
-		"d9-ehrpwm5-a", "d9-gpio", "d9-gpio-pullup", "d9-gpio-pulldown";
-
-	pinctrl-0 = <&d4_ehrpwm0_a>;
-	pinctrl-1 = <&d4_ehrpwm0_a>;
-	pinctrl-2 = <&d4_gpio>;
-	pinctrl-3 = <&d4_gpio_pullup>;
-	pinctrl-4 = <&d4_gpio_pulldown>;
-
-	pinctrl-5 = <&d5_ehrpwm1_a>;
-	pinctrl-6 = <&d5_gpio>;
-	pinctrl-7 = <&d5_gpio_pullup>;
-	pinctrl-8 = <&d5_gpio_pulldown>;
-
-	pinctrl-9 = <&d6_ehrpwm2_a>;
-	pinctrl-10 = <&d6_gpio>;
-	pinctrl-11 = <&d6_gpio_pullup>;
-	pinctrl-12 = <&d6_gpio_pulldown>;
-
-	pinctrl-13 = <&d7_ehrpwm3_a>;
-	pinctrl-14 = <&d7_gpio>;
-	pinctrl-15 = <&d7_gpio_pullup>;
-	pinctrl-16 = <&d7_gpio_pulldown>;
-
-	pinctrl-17 = <&d8_ehrpwm4_a>;
-	pinctrl-18 = <&d8_gpio>;
-	pinctrl-19 = <&d8_gpio_pullup>;
-	pinctrl-20 = <&d8_gpio_pulldown>;
-
-	pinctrl-21 = <&d9_ehrpwm5_a>;
-	pinctrl-22 = <&d9_gpio>;
-	pinctrl-23 = <&d9_gpio_pullup>;
-	pinctrl-24 = <&d9_gpio_pulldown>;
-
-	d4_ehrpwm0_a: d4-ehrpwm0-a-pins {
-		pinctrl-single,pins = <
-			/* (AG18) EHRPWM0_A */
-			AM65X_IOPAD(0x0084, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d4_gpio: d4-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AG18) GPIO0_33 */
-			AM65X_IOPAD(0x0084, PIN_INPUT, 7)
-		>;
-	};
-
-	d4_gpio_pullup: d4-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AG18) GPIO0_33 */
-			AM65X_IOPAD(0x0084, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d4_gpio_pulldown: d4-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AG18) GPIO0_33 */
-			AM65X_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d5_ehrpwm1_a: d5-ehrpwm1-a-pins {
-		pinctrl-single,pins = <
-			/* (AF17) EHRPWM1_A */
-			AM65X_IOPAD(0x008C, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d5_gpio: d5-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AF17) GPIO0_35 */
-			AM65X_IOPAD(0x008C, PIN_INPUT, 7)
-		>;
-	};
-
-	d5_gpio_pullup: d5-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AF17) GPIO0_35 */
-			AM65X_IOPAD(0x008C, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d5_gpio_pulldown: d5-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AF17) GPIO0_35 */
-			AM65X_IOPAD(0x008C, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d6_ehrpwm2_a: d6-ehrpwm2-a-pins {
-		pinctrl-single,pins = <
-			/* (AH16) EHRPWM2_A */
-			AM65X_IOPAD(0x0098, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d6_gpio: d6-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AH16) GPIO0_38 */
-			AM65X_IOPAD(0x0098, PIN_INPUT, 7)
-		>;
-	};
-
-	d6_gpio_pullup: d6-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AH16) GPIO0_38 */
-			AM65X_IOPAD(0x0098, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d6_gpio_pulldown: d6-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AH16) GPIO0_38 */
-			AM65X_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d7_ehrpwm3_a: d7-ehrpwm3-a-pins {
-		pinctrl-single,pins = <
-			/* (AH15) EHRPWM3_A */
-			AM65X_IOPAD(0x00AC, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d7_gpio: d7-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AH15) GPIO0_43 */
-			AM65X_IOPAD(0x00AC, PIN_INPUT, 7)
-		>;
-	};
-
-	d7_gpio_pullup: d7-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AH15) GPIO0_43 */
-			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d7_gpio_pulldown: d7-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AH15) GPIO0_43 */
-			AM65X_IOPAD(0x00AC, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d8_ehrpwm4_a: d8-ehrpwm4-a-pins {
-		pinctrl-single,pins = <
-			/* (AG15) EHRPWM4_A */
-			AM65X_IOPAD(0x00C0, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d8_gpio: d8-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AG15) GPIO0_48 */
-			AM65X_IOPAD(0x00C0, PIN_INPUT, 7)
-		>;
-	};
-
-	d8_gpio_pullup: d8-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AG15) GPIO0_48 */
-			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d8_gpio_pulldown: d8-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AG15) GPIO0_48 */
-			AM65X_IOPAD(0x00C0, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
-	d9_ehrpwm5_a: d9-ehrpwm5-a-pins {
-		pinctrl-single,pins = <
-			/* (AD15) EHRPWM5_A */
-			AM65X_IOPAD(0x00CC, PIN_OUTPUT, 5)
-		>;
-	};
-
-	d9_gpio: d9-gpio-pins {
-		pinctrl-single,pins = <
-			/* (AD15) GPIO0_51 */
-			AM65X_IOPAD(0x00CC, PIN_INPUT, 7)
-		>;
-	};
-
-	d9_gpio_pullup: d9-gpio-pullup-pins {
-		pinctrl-single,pins = <
-			/* (AD15) GPIO0_51 */
-			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLUP, 7)
-		>;
-	};
-
-	d9_gpio_pulldown: d9-gpio-pulldown-pins {
-		pinctrl-single,pins = <
-			/* (AD15) GPIO0_51 */
-			AM65X_IOPAD(0x00CC, PIN_INPUT_PULLDOWN, 7)
-		>;
-	};
-
 	main_pcie_enable_pins_default: main-pcie-enable-default-pins {
 		pinctrl-single,pins = <
 			AM65X_IOPAD(0x01c4, PIN_INPUT_PULLUP, 7)  /* (AH13) GPIO1_17 */
@@ -1083,57 +424,11 @@ &main_uart1 {
 	pinctrl-0 = <&main_uart1_pins_default>;
 };
 
-&mcu_uart0 {
-	status = "okay";
-};
-
-&main_gpio0 {
-	gpio-line-names =
-		"main_gpio0-base", "", "", "", "", "", "", "", "", "",
-		"", "", "", "", "", "", "", "", "", "",
-		"", "", "", "", "", "", "", "", "", "",
-		"", "", "", "IO4", "", "IO5", "", "", "IO6", "",
-		"", "", "", "IO7", "", "", "", "", "IO8", "",
-		"", "IO9";
-};
-
 &main_gpio1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_pcie_enable_pins_default>;
 };
 
-&wkup_gpio0 {
-	pinctrl-names = "default";
-	pinctrl-0 =
-		<&arduino_i2c_aio_switch_pins_default>,
-		<&arduino_io_oe_pins_default>,
-		<&push_button_pins_default>,
-		<&db9_com_mode_pins_default>;
-	gpio-line-names =
-		/* 0..9 */
-		"wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0",
-		"UART0-enable", "UART0-terminate", "", "WIFI-disable",
-		/* 10..19 */
-		"", "", "", "", "", "", "", "", "", "",
-		/* 20..29 */
-		"", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0",
-		/* 30..39 */
-		"IO1", "IO2", "", "IO3", "IO17-direction", "A5",
-		"IO16-direction", "IO15-direction", "IO14-direction", "A3",
-		/* 40..49 */
-		"", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13",
-		"IO11",
-		/* 50..51 */
-		"IO12", "IO10";
-};
-
-&wkup_i2c0 {
-	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&wkup_i2c0_pins_default>;
-	clock-frequency = <400000>;
-};
-
 &mcu_i2c0 {
 	status = "okay";
 	pinctrl-names = "default";
@@ -1151,47 +446,6 @@ psu: regulator@60 {
 		ti,vsel1-state-high;
 		ti,enable-vout-discharge;
 	};
-
-	/* D4200 */
-	pcal9535_1: gpio@20 {
-		compatible = "nxp,pcal9535";
-		reg = <0x20>;
-		#gpio-cells = <2>;
-		gpio-controller;
-		gpio-line-names =
-			"A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
-			"A5-pull", "", "",
-			"IO14-enable", "IO15-enable", "IO16-enable",
-			"IO17-enable", "IO18-enable", "IO19-enable";
-	};
-
-	/* D4201 */
-	pcal9535_2: gpio@21 {
-		compatible = "nxp,pcal9535";
-		reg = <0x21>;
-		#gpio-cells = <2>;
-		gpio-controller;
-		gpio-line-names =
-			"IO0-direction", "IO1-direction", "IO2-direction",
-			"IO3-direction", "IO4-direction", "IO5-direction",
-			"IO6-direction", "IO7-direction",
-			"IO8-direction", "IO9-direction", "IO10-direction",
-			"IO11-direction", "IO12-direction", "IO13-direction",
-			"IO19-direction";
-	};
-
-	/* D4202 */
-	pcal9535_3: gpio@25 {
-		compatible = "nxp,pcal9535";
-		reg = <0x25>;
-		#gpio-cells = <2>;
-		gpio-controller;
-		gpio-line-names =
-			"IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
-			"IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
-			"IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
-			"IO12-pull", "IO13-pull";
-	};
 };
 
 &main_i2c0 {
@@ -1292,13 +546,6 @@ &mcu_spi0 {
 	ti,pindir-d0-out-d1-in;
 };
 
-&tscadc1 {
-	status = "okay";
-	adc {
-		ti,adc-channels = <0 1 2 3 4 5>;
-	};
-};
-
 &ospi0 {
 	status = "okay";
 	pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
index 2300abe69e94..8c438f101c99 100644
--- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include "k3-am65-iot2050-common.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	memory@80000000 {
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
index 1e5d4d98b69b..2401cbe2b66c 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts
@@ -15,6 +15,7 @@
 
 #include "k3-am6548-iot2050-advanced-common.dtsi"
 #include "k3-am65-iot2050-common-pg2.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	compatible = "siemens,iot2050-advanced-m2", "ti,am654";
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
index a8ce8c891894..c1205feef54e 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts
@@ -17,6 +17,7 @@
 
 #include "k3-am6548-iot2050-advanced-common.dtsi"
 #include "k3-am65-iot2050-common-pg2.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	compatible = "siemens,iot2050-advanced-pg2", "ti,am654";
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
index 077f165bdc68..b66965f992b9 100644
--- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
@@ -17,6 +17,7 @@
 
 #include "k3-am6548-iot2050-advanced-common.dtsi"
 #include "k3-am65-iot2050-common-pg1.dtsi"
+#include "k3-am65-iot2050-arduino-connector.dtsi"
 
 / {
 	compatible = "siemens,iot2050-advanced", "ti,am654";
-- 
2.35.3

[PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

From: Baocheng Su <baocheng.su@siemens.com>

Main differences between the new variant and Advanced PG2:

1. Arduino interface is removed. Instead, an new ASIC is added for
   communicating with PLC 1200 signal modules.
2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
   avaiable.
3. DP interface is tailored down. Instead, to communicate with the
   PLC 1200 signal modules, a USB 3.0 type B connector is added but the
   signal is not USB.
4. DDR size is increased to 4 GB.
5. Two sensors are added, one tilt sensor and one light sensor.

The light sensor it not yet added to the DT at this stage as it depends
on to-be-added bindings.

Co-developed-by: Chao Zeng <chao.zeng@siemens.com>
Signed-off-by: Chao Zeng <chao.zeng@siemens.com>
Co-developed-by: Li Hua Qian <huaqian.li@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
[Jan: rebase over arduino refactoring, split-out light sensor]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm64/boot/dts/ti/Makefile               |   1 +
 .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 ++++++++++++++++++
 2 files changed, 211 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 77a347f9f47d..9b15eaad284c 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb
 dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
new file mode 100644
index 000000000000..ab3eef683890
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2023
+ *
+ * Authors:
+ *   Baocheng Su <baocheng.su@siemens.com>
+ *   Chao Zeng <chao.zeng@siemens.com>
+ *   Huaqian Li <huaqian.li@siemens.com>
+ *
+ * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2
+ * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
+ *
+ * Product homepage:
+ * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
+ */
+
+/dts-v1/;
+
+#include "k3-am6548-iot2050-advanced-common.dtsi"
+#include "k3-am65-iot2050-common-pg2.dtsi"
+
+/ {
+	compatible = "siemens,iot2050-advanced-sm", "ti,am654";
+	model = "SIMATIC IOT2050 Advanced SM";
+
+	memory@80000000 {
+		device_type = "memory";
+		/* 4G RAM */
+		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+		      <0x00000008 0x80000000 0x00000000 0x80000000>;
+	};
+
+	aliases {
+		spi1 = &main_spi0;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>;
+
+		user-led1-red {
+			gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>;
+		};
+
+		user-led1-green {
+			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&main_pmx0 {
+	main_pcie_enable_pins_default: main-pcie-enable-default-pins {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x01d8, PIN_OUTPUT, 7)  /* (AH12) GPIO1_22 */
+		>;
+	};
+
+	main_spi0_pins: main-spi0-default-pins  {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x01c4, PIN_INPUT, 0) /* (AH13) SPI0_CLK */
+			AM65X_IOPAD(0x01c8, PIN_INPUT, 0) /* (AE13) SPI0_D0 */
+			AM65X_IOPAD(0x01cc, PIN_INPUT, 0) /* (AD13) SPI0_D1 */
+			AM65X_IOPAD(0x01bc, PIN_OUTPUT, 0) /* (AG13) SPI0_CS0 */
+		>;
+	};
+};
+
+&main_pmx1 {
+	asic_spi_mux_ctrl_pin: asic-spi-mux-ctrl-default-pins {
+		pinctrl-single,pins = <
+			AM65X_IOPAD(0x0010, PIN_OUTPUT, 7)  /* (D21) GPIO1_86 */
+		>;
+	};
+};
+
+&wkup_pmx0 {
+	user1_led_pins: user1-led-default-pins {
+		pinctrl-single,pins = <
+			/* (AB1) WKUP_UART0_RXD:WKUP_GPIO0_52, as USER 1 led red */
+			AM65X_WKUP_IOPAD(0x00a0, PIN_OUTPUT, 7)
+			/* (AB5) WKUP_UART0_TXD:WKUP_GPIO0_53, as USER 1 led green */
+			AM65X_WKUP_IOPAD(0x00a4, PIN_OUTPUT, 7)
+		>;
+	};
+
+	soc_asic_pins: soc-asic-default-pins {
+		pinctrl-single,pins = <
+			AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7)  /* (P4) WKUP_GPIO0_29 */
+			AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7)  /* (P5) WKUP_GPIO0_30 */
+			AM65X_WKUP_IOPAD(0x004c, PIN_INPUT, 7)  /* (P1) WKUP_GPIO0_31 */
+		>;
+	};
+};
+
+&main_gpio0 {
+	gpio-line-names = "main_gpio0-base";
+};
+
+&main_gpio1 {
+	pinctrl-names = "default";
+	pinctrl-0 =
+		<&cp2102n_reset_pin_default>,
+		<&main_pcie_enable_pins_default>,
+		<&asic_spi_mux_ctrl_pin>;
+	gpio-line-names =
+		/* 0..9 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 10..19 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 20..29 */
+		"", "", "", "", "CP2102N-RESET", "", "", "", "", "",
+		/* 30..39 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 40..49 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 50..59 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 60..69 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 70..79 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 80..86 */
+		"", "", "", "", "", "", "ASIC-spi-mux-ctrl";
+};
+
+&wkup_gpio0 {
+	pinctrl-names = "default";
+	pinctrl-0 =
+		<&push_button_pins_default>,
+		<&db9_com_mode_pins_default>,
+		<&soc_asic_pins>;
+	gpio-line-names =
+		/* 0..9 */
+		"wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0",
+		"UART0-enable", "UART0-terminate", "", "WIFI-disable",
+		/* 10..19 */
+		"", "", "", "", "", "", "", "", "", "",
+		/* 20..29 */
+		"", "", "", "", "", "USER-button", "", "", "","ASIC-gpio-0",
+		/* 30..31 */
+		"ASIC-gpio-1", "ASIC-gpio-2";
+};
+
+&main_spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_spi0_pins>;
+
+	#address-cells = <1>;
+	#size-cells= <0>;
+};
+
+&mcu_spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcu_spi0_pins_default>;
+};
+
+&main_i2c3 {
+	accelerometer: lsm6dso@6a {
+		compatible = "st,lsm6dso";
+		reg = <0x6a>;
+	};
+
+	/delete-node/ edp-bridge@f;
+};
+
+&dss {
+	status = "disabled";
+};
+
+&dss_ports {
+	/delete-node/ port@1;
+};
+
+&serdes0 {
+	assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>;
+	assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>;
+};
+
+&serdes1 {
+	status = "disabled";
+};
+
+&pcie0_rc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&minipcie_pins_default>;
+
+	num-lanes = <1>;
+	phys = <&serdes0 PHY_TYPE_PCIE 1>;
+	phy-names = "pcie-phy0";
+	reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&pcie1_rc {
+	status = "disabled";
+};
+
+&dwc3_0 {
+	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
+				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
+	/delete-property/ phys;
+	/delete-property/ phy-names;
+};
+
+&usb0 {
+	maximum-speed = "high-speed";
+	/delete-property/ snps,dis-u1-entry-quirk;
+	/delete-property/ snps,dis-u2-entry-quirk;
+};
-- 
2.35.3

Re: [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant

[Krzysztof Kozlowski]

On 18/12/2023 17:35, Jan Kiszka wrote:
> From: Su Bao Cheng <baocheng.su@siemens.com>
> 
> This new variant is derived from the Advanced PG2 board, removing the
> Arduino interface, and adding a new ASIC for communicating with the
> PLC 1200 signal modules.
> 

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits

[Krzysztof Kozlowski]

On 18/12/2023 17:35, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> A new variant is to be added which will not have a arduino connector
> like the existing ones. Factor out all bits that are specific to this
> connector.
> 
> The split is not perfect because wkup_gpio0 is defined based on what is
> common to all variants having the connector, thus containing also
> connector-unrelated information. But this is still cleaner than
> replicating this node into all 4 variants.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------

Please use proper -B/-M/-C arguments so code movements will be detected.

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 18/12/2023 17:36, Jan Kiszka wrote:
> From: Baocheng Su <baocheng.su@siemens.com>
> 
> Main differences between the new variant and Advanced PG2:

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

> 
> 1. Arduino interface is removed. Instead, an new ASIC is added for
>    communicating with PLC 1200 signal modules.
> 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
>    avaiable.
> 3. DP interface is tailored down. Instead, to communicate with the
>    PLC 1200 signal modules, a USB 3.0 type B connector is added but the
>    signal is not USB.
> 4. DDR size is increased to 4 GB.
> 5. Two sensors are added, one tilt sensor and one light sensor.
> 
> The light sensor it not yet added to the DT at this stage as it depends
> on to-be-added bindings.
> 
> Co-developed-by: Chao Zeng <chao.zeng@siemens.com>
> Signed-off-by: Chao Zeng <chao.zeng@siemens.com>
> Co-developed-by: Li Hua Qian <huaqian.li@siemens.com>
> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
> Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
> [Jan: rebase over arduino refactoring, split-out light sensor]
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  arch/arm64/boot/dts/ti/Makefile               |   1 +
>  .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 ++++++++++++++++++
>  2 files changed, 211 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
> 
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 77a347f9f47d..9b15eaad284c 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb
>  dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb
> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
> new file mode 100644
> index 000000000000..ab3eef683890
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Siemens AG, 2023
> + *
> + * Authors:
> + *   Baocheng Su <baocheng.su@siemens.com>
> + *   Chao Zeng <chao.zeng@siemens.com>
> + *   Huaqian Li <huaqian.li@siemens.com>
> + *
> + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2
> + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
> + *
> + * Product homepage:
> + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am6548-iot2050-advanced-common.dtsi"
> +#include "k3-am65-iot2050-common-pg2.dtsi"
> +
> +/ {
> +	compatible = "siemens,iot2050-advanced-sm", "ti,am654";
> +	model = "SIMATIC IOT2050 Advanced SM";
> +
> +	memory@80000000 {
> +		device_type = "memory";
> +		/* 4G RAM */
> +		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
> +		      <0x00000008 0x80000000 0x00000000 0x80000000>;
> +	};
> +
> +	aliases {
> +		spi1 = &main_spi0;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>;
> +
> +		user-led1-red {

led-0

> +			gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>;

Missing function, missing color. Color goes as property, not as node name.

> +		};
> +
> +		user-led1-green {

led-1

> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;

Ditto


> +
> +&dwc3_0 {
> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
> +	/delete-property/ phys;
> +	/delete-property/ phy-names;

If your board need to remove phys from the SoC node, something is wrong.
Either your board or SoC.

Any removal of properties in DTS is weird and unexpected. It deserves
comments.

> +};
> +
> +&usb0 {
> +	maximum-speed = "high-speed";
> +	/delete-property/ snps,dis-u1-entry-quirk;
> +	/delete-property/ snps,dis-u2-entry-quirk;

Same questions. If SoC has quirks, how can your board be fixed? It's SoC
property... or you are using different SoC.

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits

[Jan Kiszka]

On 19.12.23 08:51, Krzysztof Kozlowski wrote:
> On 18/12/2023 17:35, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> A new variant is to be added which will not have a arduino connector
>> like the existing ones. Factor out all bits that are specific to this
>> connector.
>>
>> The split is not perfect because wkup_gpio0 is defined based on what is
>> common to all variants having the connector, thus containing also
>> connector-unrelated information. But this is still cleaner than
>> replicating this node into all 4 variants.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
> 
> Please use proper -B/-M/-C arguments so code movements will be detected.
> 

Those are in place but have no impact, likely because the source file is
still ~700 lines after the shuffling.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits

[Krzysztof Kozlowski]

On 19/12/2023 09:06, Jan Kiszka wrote:
> On 19.12.23 08:51, Krzysztof Kozlowski wrote:
>> On 18/12/2023 17:35, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> A new variant is to be added which will not have a arduino connector
>>> like the existing ones. Factor out all bits that are specific to this
>>> connector.
>>>
>>> The split is not perfect because wkup_gpio0 is defined based on what is
>>> common to all variants having the connector, thus containing also
>>> connector-unrelated information. But this is still cleaner than
>>> replicating this node into all 4 variants.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>>>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
>>
>> Please use proper -B/-M/-C arguments so code movements will be detected.
>>
> 
> Those are in place but have no impact, likely because the source file is

In place as what?

> still ~700 lines after the shuffling.

The original file has 720 lines, so if you move 750 (!) of them, I can
hardly believe the rename cannot be detected. You are basically moving
90% or 95% of file, so this must be represented with proper diff.

Your patches do not apply on next, neither on master, so it is tricky to
check.

How do you expect us to review it? Compare line by line?

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits

[Jan Kiszka]

On 19.12.23 09:12, Krzysztof Kozlowski wrote:
> On 19/12/2023 09:06, Jan Kiszka wrote:
>> On 19.12.23 08:51, Krzysztof Kozlowski wrote:
>>> On 18/12/2023 17:35, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> A new variant is to be added which will not have a arduino connector
>>>> like the existing ones. Factor out all bits that are specific to this
>>>> connector.
>>>>
>>>> The split is not perfect because wkup_gpio0 is defined based on what is
>>>> common to all variants having the connector, thus containing also
>>>> connector-unrelated information. But this is still cleaner than
>>>> replicating this node into all 4 variants.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> ---
>>>>  .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
>>>>  .../boot/dts/ti/k3-am65-iot2050-common.dtsi   | 753 -----------------
>>>
>>> Please use proper -B/-M/-C arguments so code movements will be detected.
>>>
>>
>> Those are in place but have no impact, likely because the source file is
> 
> In place as what?
> 
>> still ~700 lines after the shuffling.
> 
> The original file has 720 lines, so if you move 750 (!) of them, I can

The original file has 1446 lines - I should have noted that this goes on 
top of [1] which is already pending for 6.8 in Nishanth's tree, sorry.

Jan

[1] https://lore.kernel.org/lkml/cover.1699087938.git.jan.kiszka@siemens.com/

> hardly believe the rename cannot be detected. You are basically moving
> 90% or 95% of file, so this must be represented with proper diff.
> 
> Your patches do not apply on next, neither on master, so it is tricky to
> check.
> 
> How do you expect us to review it? Compare line by line?
> 
> Best regards,
> Krzysztof
> 

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 08:54, Krzysztof Kozlowski wrote:
> On 18/12/2023 17:36, Jan Kiszka wrote:
>> From: Baocheng Su <baocheng.su@siemens.com>
>>
>> Main differences between the new variant and Advanced PG2:
> 
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
> 
>>
>> 1. Arduino interface is removed. Instead, an new ASIC is added for
>>    communicating with PLC 1200 signal modules.
>> 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
>>    avaiable.
>> 3. DP interface is tailored down. Instead, to communicate with the
>>    PLC 1200 signal modules, a USB 3.0 type B connector is added but the
>>    signal is not USB.
>> 4. DDR size is increased to 4 GB.
>> 5. Two sensors are added, one tilt sensor and one light sensor.
>>
>> The light sensor it not yet added to the DT at this stage as it depends
>> on to-be-added bindings.
>>
>> Co-developed-by: Chao Zeng <chao.zeng@siemens.com>
>> Signed-off-by: Chao Zeng <chao.zeng@siemens.com>
>> Co-developed-by: Li Hua Qian <huaqian.li@siemens.com>
>> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
>> Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
>> [Jan: rebase over arduino refactoring, split-out light sensor]
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  arch/arm64/boot/dts/ti/Makefile               |   1 +
>>  .../dts/ti/k3-am6548-iot2050-advanced-sm.dts  | 210 ++++++++++++++++++
>>  2 files changed, 211 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
>>
>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>> index 77a347f9f47d..9b15eaad284c 100644
>> --- a/arch/arm64/boot/dts/ti/Makefile
>> +++ b/arch/arm64/boot/dts/ti/Makefile
>> @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb
>> +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb
>>  dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb
>> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
>> new file mode 100644
>> index 000000000000..ab3eef683890
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
>> @@ -0,0 +1,210 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) Siemens AG, 2023
>> + *
>> + * Authors:
>> + *   Baocheng Su <baocheng.su@siemens.com>
>> + *   Chao Zeng <chao.zeng@siemens.com>
>> + *   Huaqian Li <huaqian.li@siemens.com>
>> + *
>> + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2
>> + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
>> + *
>> + * Product homepage:
>> + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "k3-am6548-iot2050-advanced-common.dtsi"
>> +#include "k3-am65-iot2050-common-pg2.dtsi"
>> +
>> +/ {
>> +	compatible = "siemens,iot2050-advanced-sm", "ti,am654";
>> +	model = "SIMATIC IOT2050 Advanced SM";
>> +
>> +	memory@80000000 {
>> +		device_type = "memory";
>> +		/* 4G RAM */
>> +		reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
>> +		      <0x00000008 0x80000000 0x00000000 0x80000000>;
>> +	};
>> +
>> +	aliases {
>> +		spi1 = &main_spi0;
>> +	};
>> +
>> +	leds {
>> +		compatible = "gpio-leds";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>;
>> +
>> +		user-led1-red {
> 
> led-0
> 
>> +			gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>;
> 
> Missing function, missing color. Color goes as property, not as node name.
> 
>> +		};
>> +
>> +		user-led1-green {
> 
> led-1
> 
>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
> 
> Ditto
> 

This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
not introducing new ones. We can add the color properties in a separate
patch, but the node names are now part of the kernel ABI. Changing them
would break existing userland.

> 
>> +
>> +&dwc3_0 {
>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>> +	/delete-property/ phys;
>> +	/delete-property/ phy-names;
> 
> If your board need to remove phys from the SoC node, something is wrong.
> Either your board or SoC.
> 
> Any removal of properties in DTS is weird and unexpected. It deserves
> comments.

This goes along disabling USB3 which is by default enabled via
k3-am65-iot2050-common-pg2.dtsi

> 
>> +};
>> +
>> +&usb0 {
>> +	maximum-speed = "high-speed";
>> +	/delete-property/ snps,dis-u1-entry-quirk;
>> +	/delete-property/ snps,dis-u2-entry-quirk;
> 
> Same questions. If SoC has quirks, how can your board be fixed? It's SoC
> property... or you are using different SoC.
> 

Same story.

Baocheng, Zeng Chao, correct me if there is more behind that.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 09:22, Jan Kiszka wrote:
>>
>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>
>> Ditto
>>
> 
> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
> not introducing new ones. We can add the color properties in a separate


Then why aren't you overriding by phandle/label?

> patch, but the node names are now part of the kernel ABI. Changing them
> would break existing userland.

You mean label. Why node names became the ABI? Which interface exposes them?

> 
>>
>>> +
>>> +&dwc3_0 {
>>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>>> +	/delete-property/ phys;
>>> +	/delete-property/ phy-names;
>>
>> If your board need to remove phys from the SoC node, something is wrong.
>> Either your board or SoC.
>>
>> Any removal of properties in DTS is weird and unexpected. It deserves
>> comments.
> 
> This goes along disabling USB3 which is by default enabled via
> k3-am65-iot2050-common-pg2.dtsi

Isn't this mistake? Common part enables only these pieces which are
working in common hardware SoM. If your common part of hardware, which
DTSI should represent, has USB3 then why is it being disabled here? If
common hardware design does not have USB3, then why is it being enabled
in DTSI?
> 

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 09:48, Krzysztof Kozlowski wrote:
> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>
>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>
>>> Ditto
>>>
>>
>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>> not introducing new ones. We can add the color properties in a separate
> 
> 
> Then why aren't you overriding by phandle/label?
> 

We could do that as well if we added labels first (they don't exist so 
far). Not seeing any difference, though.

>> patch, but the node names are now part of the kernel ABI. Changing them
>> would break existing userland.
> 
> You mean label. Why node names became the ABI? Which interface exposes them?

root@iot2050-debian:~# ls -l /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red

>>>> +
>>>> +&dwc3_0 {
>>>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>>>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>>>> +	/delete-property/ phys;
>>>> +	/delete-property/ phy-names;
>>>
>>> If your board need to remove phys from the SoC node, something is wrong.
>>> Either your board or SoC.
>>>
>>> Any removal of properties in DTS is weird and unexpected. It deserves
>>> comments.
>>
>> This goes along disabling USB3 which is by default enabled via
>> k3-am65-iot2050-common-pg2.dtsi
> 
> Isn't this mistake? Common part enables only these pieces which are
> working in common hardware SoM. If your common part of hardware, which
> DTSI should represent, has USB3 then why is it being disabled here? If
> common hardware design does not have USB3, then why is it being enabled
> in DTSI?

It's a trade-off between adding yet another dtsi for those widely 
common bits vs. adjusting the differences of only one variant from 
that. We do the same for the Display Port so far.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 10:03, Jan Kiszka wrote:
> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>
>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>
>>>> Ditto
>>>>
>>>
>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>> not introducing new ones. We can add the color properties in a separate
>>
>>
>> Then why aren't you overriding by phandle/label?
>>
> 
> We could do that as well if we added labels first (they don't exist so 
> far). Not seeing any difference, though.
> 
>>> patch, but the node names are now part of the kernel ABI. Changing them
>>> would break existing userland.
>>
>> You mean label. Why node names became the ABI? Which interface exposes them?
> 
> root@iot2050-debian:~# ls -l /sys/class/leds/


> total 0
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
> 
>>>>> +
>>>>> +&dwc3_0 {
>>>>> +	assigned-clock-parents = <&k3_clks 151 4>,  /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */
>>>>> +				 <&k3_clks 151 9>;  /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */
>>>>> +	/delete-property/ phys;
>>>>> +	/delete-property/ phy-names;
>>>>
>>>> If your board need to remove phys from the SoC node, something is wrong.
>>>> Either your board or SoC.
>>>>
>>>> Any removal of properties in DTS is weird and unexpected. It deserves
>>>> comments.
>>>
>>> This goes along disabling USB3 which is by default enabled via
>>> k3-am65-iot2050-common-pg2.dtsi
>>
>> Isn't this mistake? Common part enables only these pieces which are
>> working in common hardware SoM. If your common part of hardware, which
>> DTSI should represent, has USB3 then why is it being disabled here? If
>> common hardware design does not have USB3, then why is it being enabled
>> in DTSI?
> 
> It's a trade-off between adding yet another dtsi for those widely 
> common bits vs. adjusting the differences of only one variant from 

You don't need to add one more DTSI to achieve proper architecture of
DTS/DTSI split.

> that. We do the same for the Display Port so far.

DTSI represents common piece of hardware, like SoM or re-usable blocks,
not trade-off.

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 10:03, Jan Kiszka wrote:
> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>
>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>
>>>> Ditto
>>>>
>>>
>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>> not introducing new ones. We can add the color properties in a separate
>>
>>
>> Then why aren't you overriding by phandle/label?
>>
> 
> We could do that as well if we added labels first (they don't exist so 
> far). Not seeing any difference, though.

Confusion? Your code suggests new node, thus you got review like you got.

> 
>>> patch, but the node names are now part of the kernel ABI. Changing them
>>> would break existing userland.
>>
>> You mean label. Why node names became the ABI? Which interface exposes them?
> 
> root@iot2050-debian:~# ls -l /sys/class/leds/
> total 0
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red

I replied too fast previous and did not include answer here:

You have label for that... Somehow all these nodes are half-baked,
without all the expected properties and now you call node name as ABI.
The node name is not the ABI.

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 10:50, Krzysztof Kozlowski wrote:
> On 19/12/2023 10:03, Jan Kiszka wrote:
>> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>>
>>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>>
>>>>> Ditto
>>>>>
>>>>
>>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>>> not introducing new ones. We can add the color properties in a separate
>>>
>>>
>>> Then why aren't you overriding by phandle/label?
>>>
>>
>> We could do that as well if we added labels first (they don't exist so 
>> far). Not seeing any difference, though.
> 
> Confusion? Your code suggests new node, thus you got review like you got.
> 
>>
>>>> patch, but the node names are now part of the kernel ABI. Changing them
>>>> would break existing userland.
>>>
>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>
>> root@iot2050-debian:~# ls -l /sys/class/leds/
>> total 0
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
> 
> I replied too fast previous and did not include answer here:
> 
> You have label for that... Somehow all these nodes are half-baked,
> without all the expected properties and now you call node name as ABI.
> The node name is not the ABI.

Well, existing userspace uses those names, and adding the properties
would break that interface. Now, does Linux do that?

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 10:54, Jan Kiszka wrote:
> On 19.12.23 10:50, Krzysztof Kozlowski wrote:
>> On 19/12/2023 10:03, Jan Kiszka wrote:
>>> On 19.12.23 09:48, Krzysztof Kozlowski wrote:
>>>> On 19/12/2023 09:22, Jan Kiszka wrote:
>>>>>>
>>>>>>> +			gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>;
>>>>>>
>>>>>> Ditto
>>>>>>
>>>>>
>>>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi,
>>>>> not introducing new ones. We can add the color properties in a separate
>>>>
>>>>
>>>> Then why aren't you overriding by phandle/label?
>>>>
>>>
>>> We could do that as well if we added labels first (they don't exist so 
>>> far). Not seeing any difference, though.
>>
>> Confusion? Your code suggests new node, thus you got review like you got.
>>
>>>
>>>>> patch, but the node names are now part of the kernel ABI. Changing them
>>>>> would break existing userland.
>>>>
>>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>>
>>> root@iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
>>
>> I replied too fast previous and did not include answer here:
>>
>> You have label for that... Somehow all these nodes are half-baked,
>> without all the expected properties and now you call node name as ABI.
>> The node name is not the ABI.
> 
> Well, existing userspace uses those names, and adding the properties
> would break that interface. Now, does Linux do that?
> 

Obviously, we could deviate from the existing naming scheme only for the
new variant, keeping it for the other 5, but that will be "fun" to maintain.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 10:54, Jan Kiszka wrote:
>>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>>
>>> root@iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
>>
>> I replied too fast previous and did not include answer here:
>>
>> You have label for that... Somehow all these nodes are half-baked,
>> without all the expected properties and now you call node name as ABI.
>> The node name is not the ABI.
> 
> Well, existing userspace uses those names, and adding the properties
> would break that interface. Now, does Linux do that?

I don't think you understood the concept. There is no change for
userspace. Same interface, same names. No ABI break.

Anyway, changing them is not part of this patchset since these are not
new nodes.

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 10:58, Krzysztof Kozlowski wrote:
> On 19/12/2023 10:54, Jan Kiszka wrote:
>>>>> You mean label. Why node names became the ABI? Which interface exposes them?
>>>>
>>>> root@iot2050-debian:~# ls -l /sys/class/leds/
>>>> total 0
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
>>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green
>>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red
>>>
>>> I replied too fast previous and did not include answer here:
>>>
>>> You have label for that... Somehow all these nodes are half-baked,
>>> without all the expected properties and now you call node name as ABI.
>>> The node name is not the ABI.
>>
>> Well, existing userspace uses those names, and adding the properties
>> would break that interface. Now, does Linux do that?
> 
> I don't think you understood the concept. There is no change for
> userspace. Same interface, same names. No ABI break.

I do understand the impact very well:
open("/sys/class/leds/user-led1-red") has to work for all the variants,
consistently and backward-compatible for userspace.

> 
> Anyway, changing them is not part of this patchset since these are not
> new nodes.

Fine, then we can leave the LED topic aside for now.

I will look into the other comments.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>
>>>> You have label for that... Somehow all these nodes are half-baked,
>>>> without all the expected properties and now you call node name as ABI.
>>>> The node name is not the ABI.
>>>
>>> Well, existing userspace uses those names, and adding the properties
>>> would break that interface. Now, does Linux do that?
>>
>> I don't think you understood the concept. There is no change for
>> userspace. Same interface, same names. No ABI break.
> 
> I do understand the impact very well:
> open("/sys/class/leds/user-led1-red") has to work for all the variants,
> consistently and backward-compatible for userspace.

And it will. The name is the same.

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 16:39, Krzysztof Kozlowski wrote:
> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>
>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>> without all the expected properties and now you call node name as ABI.
>>>>> The node name is not the ABI.
>>>>
>>>> Well, existing userspace uses those names, and adding the properties
>>>> would break that interface. Now, does Linux do that?
>>>
>>> I don't think you understood the concept. There is no change for
>>> userspace. Same interface, same names. No ABI break.
>>
>> I do understand the impact very well:
>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>> consistently and backward-compatible for userspace.
> 
> And it will. The name is the same.

Nope, it's not - I tried that already :)

root@iot2050-debian:~# ls -l /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:status -> ../../devices/platform/leds/leds/green:status
lrwxrwxrwx 1 root root 0 Dec 19 09:49 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0::
lrwxrwxrwx 1 root root 0 Dec 19 09:49 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1::
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator -> ../../devices/platform/leds/leds/red:indicator
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator_1 -> ../../devices/platform/leds/leds/red:indicator_1
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator_2 -> ../../devices/platform/leds/leds/red:indicator_2
lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:status -> ../../devices/platform/leds/leds/red:status

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 16:40, Jan Kiszka wrote:
> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>
>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>> The node name is not the ABI.
>>>>>
>>>>> Well, existing userspace uses those names, and adding the properties
>>>>> would break that interface. Now, does Linux do that?
>>>>
>>>> I don't think you understood the concept. There is no change for
>>>> userspace. Same interface, same names. No ABI break.
>>>
>>> I do understand the impact very well:
>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>> consistently and backward-compatible for userspace.
>>
>> And it will. The name is the same.
> 
> Nope, it's not - I tried that already :)
> 
> root@iot2050-debian:~# ls -l /sys/class/leds/
> total 0
> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator

And how does your DTS look like?

Because I also tried and it is exactly the same.

Best regards,
Krzysztof

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Jan Kiszka]

On 19.12.23 16:42, Krzysztof Kozlowski wrote:
> On 19/12/2023 16:40, Jan Kiszka wrote:
>> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>>
>>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>>> The node name is not the ABI.
>>>>>>
>>>>>> Well, existing userspace uses those names, and adding the properties
>>>>>> would break that interface. Now, does Linux do that?
>>>>>
>>>>> I don't think you understood the concept. There is no change for
>>>>> userspace. Same interface, same names. No ABI break.
>>>>
>>>> I do understand the impact very well:
>>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>>> consistently and backward-compatible for userspace.
>>>
>>> And it will. The name is the same.
>>
>> Nope, it's not - I tried that already :)
>>
>> root@iot2050-debian:~# ls -l /sys/class/leds/
>> total 0
>> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
> 
> And how does your DTS look like?
> 
> Because I also tried and it is exactly the same.
> 

I played with

diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
index 402afa4bc1b6..a791444eeb93 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include "k3-am654.dtsi"
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/phy/phy.h>
 #include <dt-bindings/net/ti-dp83867.h>
 
@@ -84,27 +85,39 @@ leds {
 		pinctrl-0 = <&leds_pins_default>;
 
 		status-led-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
 			panic-indicator;
 		};
 
 		status-led-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&wkup_gpio0 24 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led1-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&pcal9535_3 14 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led1-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&pcal9535_2 15 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led2-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&wkup_gpio0 17 GPIO_ACTIVE_HIGH>;
 		};
 
 		user-led2-green {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_INDICATOR;
 			gpios = <&wkup_gpio0 22 GPIO_ACTIVE_HIGH>;
 		};
 	};

Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant

[Krzysztof Kozlowski]

On 19/12/2023 16:48, Jan Kiszka wrote:
> On 19.12.23 16:42, Krzysztof Kozlowski wrote:
>> On 19/12/2023 16:40, Jan Kiszka wrote:
>>> On 19.12.23 16:39, Krzysztof Kozlowski wrote:
>>>> On 19/12/2023 16:37, Jan Kiszka wrote:
>>>>>>>>
>>>>>>>> You have label for that... Somehow all these nodes are half-baked,
>>>>>>>> without all the expected properties and now you call node name as ABI.
>>>>>>>> The node name is not the ABI.
>>>>>>>
>>>>>>> Well, existing userspace uses those names, and adding the properties
>>>>>>> would break that interface. Now, does Linux do that?
>>>>>>
>>>>>> I don't think you understood the concept. There is no change for
>>>>>> userspace. Same interface, same names. No ABI break.
>>>>>
>>>>> I do understand the impact very well:
>>>>> open("/sys/class/leds/user-led1-red") has to work for all the variants,
>>>>> consistently and backward-compatible for userspace.
>>>>
>>>> And it will. The name is the same.
>>>
>>> Nope, it's not - I tried that already :)
>>>
>>> root@iot2050-debian:~# ls -l /sys/class/leds/
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator
>>
>> And how does your DTS look like?
>>
>> Because I also tried and it is exactly the same.
>>
> 
> I played with
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> index 402afa4bc1b6..a791444eeb93 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
> @@ -10,6 +10,7 @@
>   */
>  
>  #include "k3-am654.dtsi"
> +#include <dt-bindings/leds/common.h>
>  #include <dt-bindings/phy/phy.h>
>  #include <dt-bindings/net/ti-dp83867.h>
>  
> @@ -84,27 +85,39 @@ leds {
>  		pinctrl-0 = <&leds_pins_default>;
>  
>  		status-led-red {
> +			color = <LED_COLOR_ID_RED>;
> +			function = LED_FUNCTION_STATUS;
>  			gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
>  			panic-indicator;

And where is the label property?

Please read my message again:

>> You:
>> patch, but the node names are now part of the kernel ABI. Changing
them would break existing userland.
> Me:
> You mean label. Why node names became the ABI? Which interface exposes
them?


>> You:
>> root@iot2050-debian:~# ls -l /sys/class/leds/
> Me:
> I replied too fast previous and did not include answer here:
> You have label for that...

So again: The stable ABI is fulfilled by using label property. Not the
Devicetree "label" phandle in front of the node, but the dedicated property.

Best regards,
Krzysztof