[PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board

[PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board

[Rogerio Pimentel]

Add device tree compatible string for the i.MX8MP FRDM board.

Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
---

No changes in v4

No changes in v3

No changes in v2

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

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 21b7168d61f5..f46cf6d1f502 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1099,6 +1099,7 @@ properties:
               - emcraft,imx8mp-navqp      # i.MX8MP Emcraft Systems NavQ+ Kit
               - fsl,imx8mp-evk            # i.MX8MP EVK Board
               - fsl,imx8mp-evk-revb4      # i.MX8MP EVK Rev B4 Board
+              - fsl,imx8mp-frdm           # i.MX8MP Freedom Board
               - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
               - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
               - gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
-- 
2.25.1

[PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Rogerio Pimentel]

The FRDM-i.MX8MP is an NXP development platform based on the i.MX8M Plus
SoC, featuring a quad Cortex-A53, Cortex-M7 co-processor, 4GB LPDDR4,
32GB eMMC, Wi-Fi 6/Bluetooth 5.4/802.15.4 tri-radio, Ethernet, HDMI/MIPI
display interfaces, camera connectors, and standard expansion headers.

Based on the device tree found in the NXP repository at github
https://github.com/nxp-imx-support/meta-imx-frdm and on imx8mp-evk
board kernel mainline device tree.

This is a basic device tree supporting:

 - Quad Cortex-A53
 - 4GB LPDDR4 DRAM
 - PCA9450C PMIC with regulators
 - Two NXP PCAL6416 GPIO expanders
 - RGB LEDs via GPIO expander
 - I2C1, I2C2, I2C3 controllers
 - UART2 (console) and UART3 (with RTS/CTS)
 - USDHC3 (8-bit eMMC)
 - SNVS power key (onboard power button)

Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
---

Changes in v4:

 - Change label pcal6416 to pcal6416_0

Changes in v3:

 - Removing the following tags and names added
 on v2 by mistake:
 Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
 Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
 Signed-off-by: Shawn Guo <shawnguo@kernel.org>

Changes in v2:

 - Fixed dt-binding schema warnings
 - Renamed nodes 'red, green and blue' to
   'led-0, led-1 and led-2'
 - Renamed led labels 'led-0, led-1 and led-2'
   to 'red, green and blue'
 - Added Reviewed-by and Signed-off-by tags

 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 arch/arm64/boot/dts/freescale/imx8mp-frdm.dts | 355 ++++++++++++++++++
 2 files changed, 356 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-frdm.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 75676b908299..323e98c0cb48 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -206,6 +206,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-picoitx.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-edm-g-wb.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-frdm.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-mate.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-pro.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-pulse.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
new file mode 100644
index 000000000000..242cce2f2029
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+
+/ {
+	model = "NXP i.MX8MPlus FRDM board";
+	compatible = "fsl,imx8mp-frdm", "fsl,imx8mp";
+
+	chosen {
+		stdout-path = &uart2;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			label = "red";
+			gpios = <&pcal6416_0 13 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+		};
+
+		led-1 {
+			label = "green";
+			gpios = <&pcal6416_0 14 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+		};
+
+		led-2 {
+			label = "blue";
+			gpios = <&pcal6416_0 15 GPIO_ACTIVE_HIGH>;
+			default-state = "off";
+		};
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x0 0x40000000 0 0xc0000000>,
+		      <0x1 0x00000000 0 0x40000000>;
+	};
+};
+
+&A53_0 {
+	cpu-supply = <&reg_arm>;
+};
+
+&A53_1 {
+	cpu-supply = <&reg_arm>;
+};
+
+&A53_2 {
+	cpu-supply = <&reg_arm>;
+};
+
+&A53_3 {
+	cpu-supply = <&reg_arm>;
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+
+	pmic@25 {
+		compatible = "nxp,pca9450c";
+		reg = <0x25>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pmic>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+		regulators {
+			BUCK1 {
+				regulator-name = "BUCK1";
+				regulator-min-microvolt = <720000>;
+				regulator-max-microvolt = <1000000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <3125>;
+			};
+
+			reg_arm: BUCK2 {
+				regulator-name = "BUCK2";
+				regulator-min-microvolt = <720000>;
+				regulator-max-microvolt = <1025000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <3125>;
+				nxp,dvs-run-voltage = <950000>;
+				nxp,dvs-standby-voltage = <850000>;
+			};
+
+			BUCK4 {
+				regulator-name = "BUCK4";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			reg_buck5: BUCK5 {
+				regulator-name = "BUCK5";
+				regulator-min-microvolt = <1650000>;
+				regulator-max-microvolt = <1950000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			BUCK6 {
+				regulator-name = "BUCK6";
+				regulator-min-microvolt = <1045000>;
+				regulator-max-microvolt = <1155000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			LDO1 {
+				regulator-name = "LDO1";
+				regulator-min-microvolt = <1650000>;
+				regulator-max-microvolt = <1950000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			LDO3 {
+				regulator-name = "LDO3";
+				regulator-min-microvolt = <1710000>;
+				regulator-max-microvolt = <1890000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			LDO5 {
+				regulator-name = "LDO5";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	pcal6416_0: gpio@20 {
+		compatible = "nxp,pcal6416";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcal6416_0_int>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names = "CSI1_nRST",
+			"CSI2_nRST",
+			"DSI_CTP_RST",
+			"EXT_PWREN1",
+			"CAN_STBY",
+			"EXP_P0_5",
+			"EXP_P0_6",
+			"P0_7",
+			"LVDS0_BLT_EN",
+			"LVDS1_BLT_EN",
+			"LVDS0_CTP_RST",
+			"LVDS1_CTP_RST",
+			"SPK_PWREN",
+			"RLED_GPIO",
+			"GLED_GPIO",
+			"BLED_GPIO";
+	};
+
+	pcal6416_1: gpio@21 {
+		compatible = "nxp,pcal6416";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcal6416_1_int>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+		gpio-line-names = "P0_0",
+			"P0_1",
+			"AUD_nINT",
+			"RTC_nINTA",
+			"USB1_SS_SEL",
+			"USB2_PWR_EN",
+			"SPI_EXP_SEL",
+			"P0_7",
+			"W2_HOST_WAKE_SD_3V3",
+			"W2_HOST_WAKE_BT_3V3",
+			"EXP_WIFI_BT_PDN_3V3",
+			"EXP_BT_RST_3V3",
+			"W2_RST_IND_3V3",
+			"SPI_nINT_3V3",
+			"KEYM_PCIE_nWAKE",
+			"P1_7";
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+};
+
+&snvs_pwrkey {
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3>;
+	assigned-clocks = <&clk IMX8MP_CLK_UART3>;
+	assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&usdhc3 {
+	assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
+	assigned-clock-rates = <400000000>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL	0x400001c2
+			MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA	0x400001c2
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL	0x400001c2
+			MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA	0x400001c2
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL	0x400001c2
+			MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA	0x400001c2
+		>;
+	};
+
+	pinctrl_pmic: pmicgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03	0x000001c0
+		>;
+	};
+
+	pinctrl_pcal6416_0_int: pcal6416_0_int_grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16	0x146
+		>;
+	};
+
+	pinctrl_pcal6416_1_int: pcal6416_1_int_grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11	0x146
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX	0x140
+			MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX	0x140
+		>;
+	};
+
+	pinctrl_uart3: uart3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX	0x140
+			MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX	0x140
+			MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS	0x140
+			MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS	0x140
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK	0x190
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD	0x1d0
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0	0x1d0
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1	0x1d0
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2	0x1d0
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3	0x1d0
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4	0x1d0
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5	0x1d0
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6	0x1d0
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7	0x1d0
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE	0x190
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK	0x194
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD	0x1d4
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0	0x1d4
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1	0x1d4
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2	0x1d4
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3	0x1d4
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4	0x1d4
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5	0x1d4
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6	0x1d4
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7	0x1d4
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE	0x194
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK	0x196
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD	0x1d6
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0	0x1d6
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1	0x1d6
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2	0x1d6
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3	0x1d6
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4	0x1d6
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5	0x1d6
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6	0x1d6
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7	0x1d6
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE	0x196
+		>;
+	};
+};
-- 
2.25.1

Re: [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board

[Rob Herring]

On Sun, Nov 09, 2025 at 04:45:14PM -0500, Rogerio Pimentel wrote:
> Add device tree compatible string for the i.MX8MP FRDM board.
> 
> Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
> ---
> 
> No changes in v4

Missing Conor's ack.

> 
> No changes in v3
> 
> No changes in v2
> 
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 21b7168d61f5..f46cf6d1f502 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -1099,6 +1099,7 @@ properties:
>                - emcraft,imx8mp-navqp      # i.MX8MP Emcraft Systems NavQ+ Kit
>                - fsl,imx8mp-evk            # i.MX8MP EVK Board
>                - fsl,imx8mp-evk-revb4      # i.MX8MP EVK Rev B4 Board
> +              - fsl,imx8mp-frdm           # i.MX8MP Freedom Board
>                - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
>                - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
>                - gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
> -- 
> 2.25.1
> 

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Joseph Guo]

On Sun, Nov 09, 2025 at 04:45:15PM -0500, Rogerio Pimentel wrote:
> The FRDM-i.MX8MP is an NXP development platform based on the i.MX8M Plus
> SoC, featuring a quad Cortex-A53, Cortex-M7 co-processor, 4GB LPDDR4,
> 32GB eMMC, Wi-Fi 6/Bluetooth 5.4/802.15.4 tri-radio, Ethernet, HDMI/MIPI
> display interfaces, camera connectors, and standard expansion headers.
> 
> Based on the device tree found in the NXP repository at github
> https://github.com/nxp-imx-support/meta-imx-frdm and on imx8mp-evk
> board kernel mainline device tree.

Hi Rogerio,

I'm maintainer of NXP mainline code for FRDM boards now.
Thanks for your contribution for FRDM boards upstreaming.
The imx8mp frdm board official name is FRDM-IMX8MP,
so please change the name from FRDM-i.MX8MP to FRDM-IMX8MP
in commit message.

The code you refer in meta-imx-frdm is based on 6.6.36 kernel which
is pretty old. Our new code based on 6.12 you can refer this link:
https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts

> 
> This is a basic device tree supporting:
> 
>  - Quad Cortex-A53
>  - 4GB LPDDR4 DRAM
>  - PCA9450C PMIC with regulators
>  - Two NXP PCAL6416 GPIO expanders
>  - RGB LEDs via GPIO expander
>  - I2C1, I2C2, I2C3 controllers
>  - UART2 (console) and UART3 (with RTS/CTS)
>  - USDHC3 (8-bit eMMC)
>  - SNVS power key (onboard power button)
> 
> Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> ---
> 
> Changes in v4:
> 
>  - Change label pcal6416 to pcal6416_0
> 
> Changes in v3:
> 
>  - Removing the following tags and names added
>  on v2 by mistake:
>  Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
>  Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>  Signed-off-by: Shawn Guo <shawnguo@kernel.org>
> 
> Changes in v2:
> 
>  - Fixed dt-binding schema warnings
>  - Renamed nodes 'red, green and blue' to
>    'led-0, led-1 and led-2'
>  - Renamed led labels 'led-0, led-1 and led-2'
>    to 'red, green and blue'
>  - Added Reviewed-by and Signed-off-by tags
> 
>  arch/arm64/boot/dts/freescale/Makefile        |   1 +
>  arch/arm64/boot/dts/freescale/imx8mp-frdm.dts | 355 ++++++++++++++++++
>  2 files changed, 356 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 75676b908299..323e98c0cb48 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -206,6 +206,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-picoitx.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-edm-g-wb.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-frdm.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-mate.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-pro.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx8mp-hummingboard-pulse.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
> new file mode 100644
> index 000000000000..242cce2f2029
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2019 NXP
/s/2019/2025
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8mp.dtsi"
> +
> +/ {
> +	model = "NXP i.MX8MPlus FRDM board";
> +	compatible = "fsl,imx8mp-frdm", "fsl,imx8mp";
	model = "NXP FRDM-IMX8MPLUS";
	compatible = "fsl,frdm-imx8mp", "fsl,imx8mp";
> +
> +	chosen {
> +		stdout-path = &uart2;
> +	};
> +
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +
> +		led-0 {
> +			label = "red";
> +			gpios = <&pcal6416_0 13 GPIO_ACTIVE_HIGH>;
> +			default-state = "off";
> +		};
> +
> +		led-1 {
> +			label = "green";
> +			gpios = <&pcal6416_0 14 GPIO_ACTIVE_HIGH>;
> +			default-state = "on";
> +		};
> +
> +		led-2 {
> +			label = "blue";
> +			gpios = <&pcal6416_0 15 GPIO_ACTIVE_HIGH>;
> +			default-state = "off";
> +		};
> +	};
> +
> +	memory@40000000 {
> +		device_type = "memory";
> +		reg = <0x0 0x40000000 0 0xc0000000>,
> +		      <0x1 0x00000000 0 0x40000000>;
> +	};
> +};
> +
> +&A53_0 {
> +	cpu-supply = <&reg_arm>;
> +};
> +
> +&A53_1 {
> +	cpu-supply = <&reg_arm>;
> +};
> +
> +&A53_2 {
> +	cpu-supply = <&reg_arm>;
> +};
> +
> +&A53_3 {
> +	cpu-supply = <&reg_arm>;
> +};
> +
> +&i2c1 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1>;
> +	status = "okay";
> +
> +	pmic@25 {
> +		compatible = "nxp,pca9450c";
> +		reg = <0x25>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pmic>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> +		regulators {
> +			BUCK1 {
> +				regulator-name = "BUCK1";
> +				regulator-min-microvolt = <720000>;
> +				regulator-max-microvolt = <1000000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +				regulator-ramp-delay = <3125>;
> +			};
> +
> +			reg_arm: BUCK2 {
> +				regulator-name = "BUCK2";
> +				regulator-min-microvolt = <720000>;
> +				regulator-max-microvolt = <1025000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +				regulator-ramp-delay = <3125>;
> +				nxp,dvs-run-voltage = <950000>;
> +				nxp,dvs-standby-voltage = <850000>;
> +			};
> +
> +			BUCK4 {
> +				regulator-name = "BUCK4";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3600000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			reg_buck5: BUCK5 {
> +				regulator-name = "BUCK5";
> +				regulator-min-microvolt = <1650000>;
> +				regulator-max-microvolt = <1950000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			BUCK6 {
> +				regulator-name = "BUCK6";
> +				regulator-min-microvolt = <1045000>;
> +				regulator-max-microvolt = <1155000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			LDO1 {
> +				regulator-name = "LDO1";
> +				regulator-min-microvolt = <1650000>;
> +				regulator-max-microvolt = <1950000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			LDO3 {
> +				regulator-name = "LDO3";
> +				regulator-min-microvolt = <1710000>;
> +				regulator-max-microvolt = <1890000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			LDO5 {
> +				regulator-name = "LDO5";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
> +
> +	pcal6416_0: gpio@20 {
> +		compatible = "nxp,pcal6416";
> +		reg = <0x20>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pcal6416_0_int>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names = "CSI1_nRST",
> +			"CSI2_nRST",
> +			"DSI_CTP_RST",
> +			"EXT_PWREN1",
> +			"CAN_STBY",
> +			"EXP_P0_5",
> +			"EXP_P0_6",
> +			"P0_7",
> +			"LVDS0_BLT_EN",
> +			"LVDS1_BLT_EN",
> +			"LVDS0_CTP_RST",
> +			"LVDS1_CTP_RST",
> +			"SPK_PWREN",
> +			"RLED_GPIO",
> +			"GLED_GPIO",
> +			"BLED_GPIO";
> +	};
> +
> +	pcal6416_1: gpio@21 {
> +		compatible = "nxp,pcal6416";
> +		reg = <0x21>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		interrupt-controller;
> +		#interrupt-cells = <2>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pcal6416_1_int>;
> +		interrupt-parent = <&gpio2>;
> +		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> +		gpio-line-names = "P0_0",
> +			"P0_1",
> +			"AUD_nINT",
> +			"RTC_nINTA",
> +			"USB1_SS_SEL",
> +			"USB2_PWR_EN",
> +			"SPI_EXP_SEL",
> +			"P0_7",
> +			"W2_HOST_WAKE_SD_3V3",
> +			"W2_HOST_WAKE_BT_3V3",
> +			"EXP_WIFI_BT_PDN_3V3",
> +			"EXP_BT_RST_3V3",
> +			"W2_RST_IND_3V3",
> +			"SPI_nINT_3V3",
> +			"KEYM_PCIE_nWAKE",
> +			"P1_7";
> +	};
> +};
> +
> +&i2c2 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +};
> +
> +&i2c3 {
> +	clock-frequency = <400000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +	status = "okay";
> +};
> +
> +&snvs_pwrkey {
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2>;
> +	status = "okay";
> +};
> +
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart3>;
> +	assigned-clocks = <&clk IMX8MP_CLK_UART3>;
> +	assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
> +	uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&usdhc3 {
> +	assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
> +	assigned-clock-rates = <400000000>;
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc3>;
> +	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> +	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> +	bus-width = <8>;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +	pinctrl_i2c1: i2c1grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL	0x400001c2
> +			MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA	0x400001c2
> +		>;
> +	};
> +
> +	pinctrl_i2c2: i2c2grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL	0x400001c2
> +			MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA	0x400001c2
> +		>;
> +	};
> +
> +	pinctrl_i2c3: i2c3grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL	0x400001c2
> +			MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA	0x400001c2
> +		>;
> +	};
> +
> +	pinctrl_pmic: pmicgrp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03	0x000001c0
> +		>;
> +	};
> +
> +	pinctrl_pcal6416_0_int: pcal6416_0_int_grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16	0x146
> +		>;
> +	};
> +
> +	pinctrl_pcal6416_1_int: pcal6416_1_int_grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11	0x146
> +		>;
> +	};
> +
> +	pinctrl_uart2: uart2grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX	0x140
> +			MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX	0x140
> +		>;
> +	};
> +
> +	pinctrl_uart3: uart3grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX	0x140
> +			MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX	0x140
> +			MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS	0x140
> +			MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS	0x140
> +		>;
> +	};
> +
> +	pinctrl_usdhc3: usdhc3grp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK	0x190
> +			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD	0x1d0
> +			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0	0x1d0
> +			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1	0x1d0
> +			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2	0x1d0
> +			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3	0x1d0
> +			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4	0x1d0
> +			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5	0x1d0
> +			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6	0x1d0
> +			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7	0x1d0
> +			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE	0x190
> +		>;
> +	};
> +
> +	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK	0x194
> +			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD	0x1d4
> +			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0	0x1d4
> +			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1	0x1d4
> +			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2	0x1d4
> +			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3	0x1d4
> +			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4	0x1d4
> +			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5	0x1d4
> +			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6	0x1d4
> +			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7	0x1d4
> +			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE	0x194
> +		>;
> +	};
> +
> +	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK	0x196
> +			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD	0x1d6
> +			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0	0x1d6
> +			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1	0x1d6
> +			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2	0x1d6
> +			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3	0x1d6
> +			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4	0x1d6
> +			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5	0x1d6
> +			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6	0x1d6
> +			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7	0x1d6
> +			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE	0x196
> +		>;
> +	};
> +};
> -- 
> 2.25.1
> 

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Fabio Estevam]

Hi Joseph,

On Mon, Nov 10, 2025 at 2:15 AM Joseph Guo <qijian.guo@nxp.com> wrote:

> > +/ {
> > +     model = "NXP i.MX8MPlus FRDM board";
> > +     compatible = "fsl,imx8mp-frdm", "fsl,imx8mp";
>         model = "NXP FRDM-IMX8MPLUS";
>         compatible = "fsl,frdm-imx8mp", "fsl,imx8mp";

Why do you suggest changing the compatible string?

"fsl,imx8mp-frdm", "fsl,imx8mp"; is correct.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Krzysztof Kozlowski]

On 09/11/2025 22:45, Rogerio Pimentel wrote:
> The FRDM-i.MX8MP is an NXP development platform based on the i.MX8M Plus
> SoC, featuring a quad Cortex-A53, Cortex-M7 co-processor, 4GB LPDDR4,
> 32GB eMMC, Wi-Fi 6/Bluetooth 5.4/802.15.4 tri-radio, Ethernet, HDMI/MIPI
> display interfaces, camera connectors, and standard expansion headers.
> 
> Based on the device tree found in the NXP repository at github
> https://github.com/nxp-imx-support/meta-imx-frdm and on imx8mp-evk
> board kernel mainline device tree.
> 
> This is a basic device tree supporting:
> 
>  - Quad Cortex-A53
>  - 4GB LPDDR4 DRAM
>  - PCA9450C PMIC with regulators
>  - Two NXP PCAL6416 GPIO expanders
>  - RGB LEDs via GPIO expander
>  - I2C1, I2C2, I2C3 controllers
>  - UART2 (console) and UART3 (with RTS/CTS)
>  - USDHC3 (8-bit eMMC)
>  - SNVS power key (onboard power button)
> 
> Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>

Incorrect DCO chain. Please look at submitting patches which explain
what is DCO and how it should be organized.

> ---
> 
> Changes in v4:




> +
> +	pinctrl_pmic: pmicgrp {
> +		fsl,pins = <
> +			MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03	0x000001c0
> +		>;
> +	};
> +
> +	pinctrl_pcal6416_0_int: pcal6416_0_int_grp {


Don't use underscores in node names. See DTS coding style.

Best regards,
Krzysztof

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Krzysztof Kozlowski]

On 10/11/2025 06:15, Joseph Guo wrote:
> On Sun, Nov 09, 2025 at 04:45:15PM -0500, Rogerio Pimentel wrote:
>> The FRDM-i.MX8MP is an NXP development platform based on the i.MX8M Plus
>> SoC, featuring a quad Cortex-A53, Cortex-M7 co-processor, 4GB LPDDR4,
>> 32GB eMMC, Wi-Fi 6/Bluetooth 5.4/802.15.4 tri-radio, Ethernet, HDMI/MIPI
>> display interfaces, camera connectors, and standard expansion headers.
>>
>> Based on the device tree found in the NXP repository at github
>> https://github.com/nxp-imx-support/meta-imx-frdm and on imx8mp-evk
>> board kernel mainline device tree.
> 
> Hi Rogerio,
> 
> I'm maintainer of NXP mainline code for FRDM boards now.
> Thanks for your contribution for FRDM boards upstreaming.
> The imx8mp frdm board official name is FRDM-IMX8MP,
> so please change the name from FRDM-i.MX8MP to FRDM-IMX8MP
> in commit message.
> 
> The code you refer in meta-imx-frdm is based on 6.6.36 kernel which
> is pretty old. Our new code based on 6.12 you can refer this link:
> https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx8mp-frdm.dts


It is still downstream, unfortunately we do not care about it. Don't use
it as arguments, please, it really does not matter what is happening in
the downstream in NXP.

Best regards,
Krzysztof

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Daniel Baluta]

On Mon, Nov 10, 2025 at 10:12 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 09/11/2025 22:45, Rogerio Pimentel wrote:
> > The FRDM-i.MX8MP is an NXP development platform based on the i.MX8M Plus
> > SoC, featuring a quad Cortex-A53, Cortex-M7 co-processor, 4GB LPDDR4,
> > 32GB eMMC, Wi-Fi 6/Bluetooth 5.4/802.15.4 tri-radio, Ethernet, HDMI/MIPI
> > display interfaces, camera connectors, and standard expansion headers.
> >
> > Based on the device tree found in the NXP repository at github
> > https://github.com/nxp-imx-support/meta-imx-frdm and on imx8mp-evk
> > board kernel mainline device tree.
> >
> > This is a basic device tree supporting:
> >
> >  - Quad Cortex-A53
> >  - 4GB LPDDR4 DRAM
> >  - PCA9450C PMIC with regulators
> >  - Two NXP PCAL6416 GPIO expanders
> >  - RGB LEDs via GPIO expander
> >  - I2C1, I2C2, I2C3 controllers
> >  - UART2 (console) and UART3 (with RTS/CTS)
> >  - USDHC3 (8-bit eMMC)
> >  - SNVS power key (onboard power button)
> >
> > Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
> > Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
>
> Incorrect DCO chain. Please look at submitting patches which explain
> what is DCO and how it should be organized.

In addition to that, Rogerio please read:

https://docs.kernel.org/process/submitting-patches.html

At this moment I think you should keep the original author of the
patch.

Then mark your contribution as follows. If you just picked the patches
tested them and made minor modifictions only add your S-o-b

e.g

Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>

If you made significant changes add your C-d-b like this:

Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
Co-developed-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Daniel Baluta]

Hello Fabio, Rogerio,

> On Mon, Nov 10, 2025 at 2:15 AM Joseph Guo <qijian.guo@nxp.com> wrote:
>
> > > +/ {
> > > +     model = "NXP i.MX8MPlus FRDM board";
> > > +     compatible = "fsl,imx8mp-frdm", "fsl,imx8mp";
> >         model = "NXP FRDM-IMX8MPLUS";
> >         compatible = "fsl,frdm-imx8mp", "fsl,imx8mp";
>
> Why do you suggest changing the compatible string?
>
> "fsl,imx8mp-frdm", "fsl,imx8mp"; is correct.
>

All NXP documentation refers to this as FRDM-IMX8MPLUS.

But compatible strings have a certain pattern to be followed so
we should really go with: "fsl,imx8mp-frdm",

But for model and all references in text and commit message
we should follow the documentation and use  FRDM-IMX8MPLUS.

So, model should be  model = "NXP FRDM-IMX8MPLUS";

Thanks,
Daniel.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Fabio Estevam]

Hi Daniel,

On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:

> In addition to that, Rogerio please read:
>
> https://docs.kernel.org/process/submitting-patches.html
>
> At this moment I think you should keep the original author of the
> patch.

Right, but NXP makes a total mess with authorship.

Please see this version from February that states the original author
as Xiaofeng Wei <xiaofeng.wei@nxp.com>:

https://github.com/nxp-imx-support/meta-imx-frdm/blob/lf-6.6.36-2.1.0/meta-imx-bsp/recipes-kernel/linux/linux-imx/0023-arm64-dts-Add-i.MX8MP-FRDM-board-support.patch

Then this one from July states the original author as Joseph Guo
<qijian.guo@nxp.com> and it also has:

Signed-off-by: Steven Yang <steven.yang@nxp.com>
Signed-off-by: Lei Xu <lei.xu@nxp.com>

https://github.com/nxp-imx/linux-imx/commit/fd8010b46bb00344fa519c73b643fad71da5887b

How are we supposed to know the correct authorship tags from the NXP
commit, then?

> Then mark your contribution as follows. If you just picked the patches
> tested them and made minor modifictions only add your S-o-b
>
> e.g
>
> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
>
> If you made significant changes add your C-d-b like this:
>
> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> Co-developed-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
> Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>

Rogerio's changes are significant as the dt-schema passes now.

The NXP commit has all the dt-schema warnings found in downstream BSPs.

For example, it makes the old mistake of describing:

 spidev1: spi@0 {
   reg = <0>;
    compatible = "lwn,bk4";
    spi-max-frequency = <1000000>;
 };

Which is totally wrong.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Daniel Baluta]

On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Daniel,
>
> On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> > In addition to that, Rogerio please read:
> >
> > https://docs.kernel.org/process/submitting-patches.html
> >
> > At this moment I think you should keep the original author of the
> > patch.
>
> Right, but NXP makes a total mess with authorship.

I cannot disagree with you on this, let me clarify it internally with
NXP colleagues
and sort everything out.

My guess is that when the code was released via the meta-imx-frdm Yocto layer
the original authorship was lost.

Anyhow, what is important for me personally is to have upstream quality code.
Also, in all fairness we should grant authorship to NXP people and follow

https://docs.kernel.org/process/submitting-patches.html

Thanks a lot for all your help and effort!

Daniel.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Daniel Baluta]

On Tue, Nov 11, 2025 at 2:49 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > Hi Daniel,
> >
> > On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
> >
> > > In addition to that, Rogerio please read:
> > >
> > > https://docs.kernel.org/process/submitting-patches.html
> > >
> > > At this moment I think you should keep the original author of the
> > > patch.
> >
> > Right, but NXP makes a total mess with authorship.
>
> I cannot disagree with you on this, let me clarify it internally with
> NXP colleagues
> and sort everything out.

Hi Fabio & Rogerio,

Checked internally and to track the correct authorship and development work
here is how NXP would prefer to get credit.

#Use git commit --amend --author="Xiaofeng Wei <xiaofeng.wei@nxp.com>"
Author: Xiaofeng Wei <xiaofeng.wei@nxp.com>

Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>

Co-developed-by: Joseph Guo <qijian.guo@nxp.com>
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>

Co-developed-by: Steven Yang <steven.yang@nxp.com>
Signed-off-by: Steven Yang <steven.yang@nxp.com>

Co-developed-by: Lei Xu <lei.xu@nxp.com>
Signed-off-by: Lei Xu <lei.xu@nxp.com>

Then you can add your own C-d-b and S-o-b.

Thanks,
Daniel.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Krzysztof Kozlowski]

On 12/11/2025 09:15, Daniel Baluta wrote:
> On Tue, Nov 11, 2025 at 2:49 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>
>> On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@gmail.com> wrote:
>>>
>>> Hi Daniel,
>>>
>>> On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>>
>>>> In addition to that, Rogerio please read:
>>>>
>>>> https://docs.kernel.org/process/submitting-patches.html
>>>>
>>>> At this moment I think you should keep the original author of the
>>>> patch.
>>>
>>> Right, but NXP makes a total mess with authorship.
>>
>> I cannot disagree with you on this, let me clarify it internally with
>> NXP colleagues
>> and sort everything out.
> 
> Hi Fabio & Rogerio,
> 
> Checked internally and to track the correct authorship and development work
> here is how NXP would prefer to get credit.

Sorry, but individual contributors do not need to give any credits to
NXP. If NXP wanted to sent the patches to have credit, they would do it.

Did sending happened?

If not, then any contributor is rightful to take the patches from
downstream and send them only, ONLY with their authorship. That's what
DCO allows and that's what established practice as well.

NXP had a chance to upstream. When they decided not to, they forfeit any
rights to claim they want any authorship.


> 
> #Use git commit --amend --author="Xiaofeng Wei <xiaofeng.wei@nxp.com>"

NAK, there is no single patch like that from above author:

https://lore.kernel.org/all/?q=f%3Axiaofeng.wei%40nxp.com

Remember, downstream code does not matter. Does not exist.


> Author: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> 
> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> 
> Co-developed-by: Joseph Guo <qijian.guo@nxp.com>
> Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
> 
> Co-developed-by: Steven Yang <steven.yang@nxp.com>
> Signed-off-by: Steven Yang <steven.yang@nxp.com>
> 
> Co-developed-by: Lei Xu <lei.xu@nxp.com>
> Signed-off-by: Lei Xu <lei.xu@nxp.com>
> 
> Then you can add your own C-d-b and S-o-b.
> 
> Thanks,
> Daniel.


Best regards,
Krzysztof

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Krzysztof Kozlowski]

On 12/11/2025 10:08, Krzysztof Kozlowski wrote:
> On 12/11/2025 09:15, Daniel Baluta wrote:
>> On Tue, Nov 11, 2025 at 2:49 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>>
>>> On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@gmail.com> wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>> On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>>>
>>>>> In addition to that, Rogerio please read:
>>>>>
>>>>> https://docs.kernel.org/process/submitting-patches.html
>>>>>
>>>>> At this moment I think you should keep the original author of the
>>>>> patch.
>>>>
>>>> Right, but NXP makes a total mess with authorship.
>>>
>>> I cannot disagree with you on this, let me clarify it internally with
>>> NXP colleagues
>>> and sort everything out.
>>
>> Hi Fabio & Rogerio,
>>
>> Checked internally and to track the correct authorship and development work
>> here is how NXP would prefer to get credit.
> 
> Sorry, but individual contributors do not need to give any credits to
> NXP. If NXP wanted to sent the patches to have credit, they would do it.
> 
> Did sending happened?
> 
> If not, then any contributor is rightful to take the patches from
> downstream and send them only, ONLY with their authorship. That's what
> DCO allows and that's what established practice as well.
> 
> NXP had a chance to upstream. When they decided not to, they forfeit any
> rights to claim they want any authorship.
> 
> 
>>
>> #Use git commit --amend --author="Xiaofeng Wei <xiaofeng.wei@nxp.com>"
> 
> NAK, there is no single patch like that from above author:
> 
> https://lore.kernel.org/all/?q=f%3Axiaofeng.wei%40nxp.com
> 
> Remember, downstream code does not matter. Does not exist.
> 
> 


... and because last two months there were two or three cases where
vendor companies bullied individual contributors, I will be quite strict
about that. Vendor company does not receive any authorship on patches
sent by independent contributors which the vendor NEVER submitted,
unless author really wants that. But I will treat any such insisting on
authorship by vendor like NXP as bullying and working AGAINST the community.

Best regards,
Krzysztof

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Daniel Baluta]

On Wed, Nov 12, 2025 at 11:14 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 12/11/2025 10:08, Krzysztof Kozlowski wrote:
> > On 12/11/2025 09:15, Daniel Baluta wrote:
> >> On Tue, Nov 11, 2025 at 2:49 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
> >>>
> >>> On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>>>
> >>>> Hi Daniel,
> >>>>
> >>>> On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
> >>>>
> >>>>> In addition to that, Rogerio please read:
> >>>>>
> >>>>> https://docs.kernel.org/process/submitting-patches.html
> >>>>>
> >>>>> At this moment I think you should keep the original author of the
> >>>>> patch.
> >>>>
> >>>> Right, but NXP makes a total mess with authorship.
> >>>
> >>> I cannot disagree with you on this, let me clarify it internally with
> >>> NXP colleagues
> >>> and sort everything out.
> >>
> >> Hi Fabio & Rogerio,
> >>
> >> Checked internally and to track the correct authorship and development work
> >> here is how NXP would prefer to get credit.
> >
> > Sorry, but individual contributors do not need to give any credits to
> > NXP. If NXP wanted to sent the patches to have credit, they would do it.
> >
> > Did sending happened?
> >
> > If not, then any contributor is rightful to take the patches from
> > downstream and send them only, ONLY with their authorship. That's what
> > DCO allows and that's what established practice as well.
> >
> > NXP had a chance to upstream. When they decided not to, they forfeit any
> > rights to claim they want any authorship.
> >
> >
> >>
> >> #Use git commit --amend --author="Xiaofeng Wei <xiaofeng.wei@nxp.com>"
> >
> > NAK, there is no single patch like that from above author:
> >
> > https://lore.kernel.org/all/?q=f%3Axiaofeng.wei%40nxp.com
> >
> > Remember, downstream code does not matter. Does not exist.
> >
> >
>
>
> ... and because last two months there were two or three cases where
> vendor companies bullied individual contributors, I will be quite strict
> about that. Vendor company does not receive any authorship on patches
> sent by independent contributors which the vendor NEVER submitted,
> unless author really wants that. But I will treat any such insisting on
> authorship by vendor like NXP as bullying and working AGAINST the community.

I'm sorry that people use "bully" in this context. We are just trying
to help with
the limited time we have and create a friendly environment around NXP
upstream support.

We (NXP) immensely  appreciate individual contributions from everyone.

We need to be fair, the v1 of this patchset was taken from NXP
downstream without
respecting the Developer Certificate of Origin.

E.g there were commits pulled in from our internal tree without
keeping the S-o-B tags.
As I said keeping the original author is a sign of respecting the
initial work of NXP developers
and a recommendation from NXP.

What is your suggestion on moving on with this? Would keeping the
authorship from Rogerio
and adding S-o-B and C-d-b tags as above work for everyone?


Daniel.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Krzysztof Kozlowski]

On 12/11/2025 10:32, Daniel Baluta wrote:
> On Wed, Nov 12, 2025 at 11:14 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 12/11/2025 10:08, Krzysztof Kozlowski wrote:
>>> On 12/11/2025 09:15, Daniel Baluta wrote:
>>>> On Tue, Nov 11, 2025 at 2:49 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>>>>
>>>>> On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@gmail.com> wrote:
>>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>>>>>>
>>>>>>> In addition to that, Rogerio please read:
>>>>>>>
>>>>>>> https://docs.kernel.org/process/submitting-patches.html
>>>>>>>
>>>>>>> At this moment I think you should keep the original author of the
>>>>>>> patch.
>>>>>>
>>>>>> Right, but NXP makes a total mess with authorship.
>>>>>
>>>>> I cannot disagree with you on this, let me clarify it internally with
>>>>> NXP colleagues
>>>>> and sort everything out.
>>>>
>>>> Hi Fabio & Rogerio,
>>>>
>>>> Checked internally and to track the correct authorship and development work
>>>> here is how NXP would prefer to get credit.
>>>
>>> Sorry, but individual contributors do not need to give any credits to
>>> NXP. If NXP wanted to sent the patches to have credit, they would do it.
>>>
>>> Did sending happened?
>>>
>>> If not, then any contributor is rightful to take the patches from
>>> downstream and send them only, ONLY with their authorship. That's what
>>> DCO allows and that's what established practice as well.
>>>
>>> NXP had a chance to upstream. When they decided not to, they forfeit any
>>> rights to claim they want any authorship.
>>>
>>>
>>>>
>>>> #Use git commit --amend --author="Xiaofeng Wei <xiaofeng.wei@nxp.com>"
>>>
>>> NAK, there is no single patch like that from above author:
>>>
>>> https://lore.kernel.org/all/?q=f%3Axiaofeng.wei%40nxp.com
>>>
>>> Remember, downstream code does not matter. Does not exist.
>>>
>>>
>>
>>
>> ... and because last two months there were two or three cases where
>> vendor companies bullied individual contributors, I will be quite strict
>> about that. Vendor company does not receive any authorship on patches
>> sent by independent contributors which the vendor NEVER submitted,
>> unless author really wants that. But I will treat any such insisting on
>> authorship by vendor like NXP as bullying and working AGAINST the community.
> 
> I'm sorry that people use "bully" in this context. We are just trying
> to help with
> the limited time we have and create a friendly environment around NXP
> upstream support.
> 
> We (NXP) immensely  appreciate individual contributions from everyone.
> 
> We need to be fair, the v1 of this patchset was taken from NXP
> downstream without
> respecting the Developer Certificate of Origin.

No, it wasn't. Please read carefully DCO. The chain here was not
correct, but that's the only thing.

> 
> E.g there were commits pulled in from our internal tree without
> keeping the S-o-B tags.

Read DCO, please. It is not mandatory to keep 3rd party SoB. It is
perfectly fine to skip it, if needed according to (b) of DCO certifying.

Otherwise please point me which aspect of certification was not kept or
was broken.

> As I said keeping the original author is a sign of respecting the
> initial work of NXP developers
> and a recommendation from NXP.

Which is purely up to the author. The NXP made their choice by not ever
sending it to upstream.

> 
> What is your suggestion on moving on with this? Would keeping the
> authorship from Rogerio
> and adding S-o-B and C-d-b tags as above work for everyone?
To me it is pretty simple and that's what I commented on - I expect
conforming to submitting patches and DCO, thus the sender's SoB MUST BE
ALWAYS the last.

This is the only issue with this patch.

Now, whom Rogerio wants to make the author I really do not care.
Although I care a lot about NXP coming to upstream and claiming they
have any authorship of their downstream code.

Assuming this was even taken from downstream, which was not proven yet,
although does not matter.

Again, whatever you have downstream absolutely does not matter, EXCEPT
THE LICENSE, for us.


Best regards,
Krzysztof

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Daniel Baluta]

<snip>

> > We (NXP) immensely  appreciate individual contributions from everyone.
> >
> > We need to be fair, the v1 of this patchset was taken from NXP
> > downstream without
> > respecting the Developer Certificate of Origin.
>
> No, it wasn't. Please read carefully DCO. The chain here was not
> correct, but that's the only thing.
>

Indeed carefully reading the DCO Clause b) you are right.

> >
> > E.g there were commits pulled in from our internal tree without
> > keeping the S-o-B tags.
>
> Read DCO, please. It is not mandatory to keep 3rd party SoB. It is
> perfectly fine to skip it, if needed according to (b) of DCO certifying.
>

True. In my understanding though if one bases their work on others work
they should at least keep the S-o-b tag as a common courtesy.

Commit messages explicitly says that the work is based on NXP internal
tree patches.

At this point I leave to Rogerio's appreciation on which S-o-B flags
to pull and how much
of his work is based on NXP tree.

Thanks a lot Rogerio and Krzysztof for helping move this forward.

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Rogerio Pimentel]

On Wed, Nov 12, 2025 at 7:33 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> <snip>
>
> > > We (NXP) immensely  appreciate individual contributions from everyone.
> > >
> > > We need to be fair, the v1 of this patchset was taken from NXP
> > > downstream without
> > > respecting the Developer Certificate of Origin.
> >
> > No, it wasn't. Please read carefully DCO. The chain here was not
> > correct, but that's the only thing.
> >
>
> Indeed carefully reading the DCO Clause b) you are right.
>
> > >
> > > E.g there were commits pulled in from our internal tree without
> > > keeping the S-o-B tags.
> >
> > Read DCO, please. It is not mandatory to keep 3rd party SoB. It is
> > perfectly fine to skip it, if needed according to (b) of DCO certifying.
> >
>
> True. In my understanding though if one bases their work on others work
> they should at least keep the S-o-b tag as a common courtesy.
>
> Commit messages explicitly says that the work is based on NXP internal
> tree patches.
>
> At this point I leave to Rogerio's appreciation on which S-o-B flags
> to pull and how much
> of his work is based on NXP tree.
>
> Thanks a lot Rogerio and Krzysztof for helping move this forward.

Thanks Daniel, Krzysztof and Fabio for the review and discussion.
I understand and agree with Krzysztof's point, but if there are no problems,
I would like to keep all the names suggested by Daniel:

Author: Xiaofeng Wei <xiaofeng.wei@nxp.com>

Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>

Co-developed-by: Joseph Guo <qijian.guo@nxp.com>
Signed-off-by: Joseph Guo <qijian.guo@nxp.com>

Co-developed-by: Steven Yang <steven.yang@nxp.com>
Signed-off-by: Steven Yang <steven.yang@nxp.com>

Co-developed-by: Lei Xu <lei.xu@nxp.com>
Signed-off-by: Lei Xu <lei.xu@nxp.com>

Co-developed-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>

Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

[Krzysztof Kozlowski]

On 12/11/2025 15:04, Rogerio Pimentel wrote:
> Author: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> 
> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com>
> 
> Co-developed-by: Joseph Guo <qijian.guo@nxp.com>
> Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
> 
> Co-developed-by: Steven Yang <steven.yang@nxp.com>
> Signed-off-by: Steven Yang <steven.yang@nxp.com>
> 
> Co-developed-by: Lei Xu <lei.xu@nxp.com>
> Signed-off-by: Lei Xu <lei.xu@nxp.com>
> 
> Co-developed-by: Rogerio Pimentel <rpimentel.silva@gmail.com>
> Signed-off-by: Rogerio Pimentel <rpimentel.silva@gmail.com>

ack.

Best regards,
Krzysztof