* [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board @ 2025-11-09 21:45 Rogerio Pimentel 2025-11-09 21:45 ` [PATCH v4 2/2] arm64: dts: add support for NXP " Rogerio Pimentel 2025-11-10 1:04 ` [PATCH v4 1/2] dt-bindings: arm: fsl: Add " Rob Herring 0 siblings, 2 replies; 19+ messages in thread From: Rogerio Pimentel @ 2025-11-09 21:45 UTC (permalink / raw) To: robh, krzk+dt, conor+dt, shawnguo, s.hauer Cc: kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-09 21:45 [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board Rogerio Pimentel @ 2025-11-09 21:45 ` Rogerio Pimentel 2025-11-10 5:15 ` Joseph Guo 2025-11-10 20:12 ` Krzysztof Kozlowski 2025-11-10 1:04 ` [PATCH v4 1/2] dt-bindings: arm: fsl: Add " Rob Herring 1 sibling, 2 replies; 19+ messages in thread From: Rogerio Pimentel @ 2025-11-09 21:45 UTC (permalink / raw) To: robh, krzk+dt, conor+dt, shawnguo, s.hauer Cc: kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Rogerio Pimentel, Xiaofeng Wei 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 = <®_arm>; +}; + +&A53_1 { + cpu-supply = <®_arm>; +}; + +&A53_2 { + cpu-supply = <®_arm>; +}; + +&A53_3 { + cpu-supply = <®_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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-09 21:45 ` [PATCH v4 2/2] arm64: dts: add support for NXP " Rogerio Pimentel @ 2025-11-10 5:15 ` Joseph Guo 2025-11-10 19:26 ` Fabio Estevam 2025-11-10 20:14 ` Krzysztof Kozlowski 2025-11-10 20:12 ` Krzysztof Kozlowski 1 sibling, 2 replies; 19+ messages in thread From: Joseph Guo @ 2025-11-10 5:15 UTC (permalink / raw) To: Rogerio Pimentel Cc: robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Justin Jiang 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 = <®_arm>; > +}; > + > +&A53_1 { > + cpu-supply = <®_arm>; > +}; > + > +&A53_2 { > + cpu-supply = <®_arm>; > +}; > + > +&A53_3 { > + cpu-supply = <®_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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-10 5:15 ` Joseph Guo @ 2025-11-10 19:26 ` Fabio Estevam 2025-11-11 10:22 ` Daniel Baluta 2025-11-10 20:14 ` Krzysztof Kozlowski 1 sibling, 1 reply; 19+ messages in thread From: Fabio Estevam @ 2025-11-10 19:26 UTC (permalink / raw) To: Joseph Guo Cc: Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Justin Jiang 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-10 19:26 ` Fabio Estevam @ 2025-11-11 10:22 ` Daniel Baluta 0 siblings, 0 replies; 19+ messages in thread From: Daniel Baluta @ 2025-11-11 10:22 UTC (permalink / raw) To: Fabio Estevam Cc: Joseph Guo, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Justin Jiang 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-10 5:15 ` Joseph Guo 2025-11-10 19:26 ` Fabio Estevam @ 2025-11-10 20:14 ` Krzysztof Kozlowski 1 sibling, 0 replies; 19+ messages in thread From: Krzysztof Kozlowski @ 2025-11-10 20:14 UTC (permalink / raw) To: Joseph Guo, Rogerio Pimentel Cc: robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Justin Jiang 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-09 21:45 ` [PATCH v4 2/2] arm64: dts: add support for NXP " Rogerio Pimentel 2025-11-10 5:15 ` Joseph Guo @ 2025-11-10 20:12 ` Krzysztof Kozlowski 2025-11-11 8:47 ` Daniel Baluta 1 sibling, 1 reply; 19+ messages in thread From: Krzysztof Kozlowski @ 2025-11-10 20:12 UTC (permalink / raw) To: Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer Cc: kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-10 20:12 ` Krzysztof Kozlowski @ 2025-11-11 8:47 ` Daniel Baluta 2025-11-11 11:50 ` Fabio Estevam 0 siblings, 1 reply; 19+ messages in thread From: Daniel Baluta @ 2025-11-11 8:47 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-11 8:47 ` Daniel Baluta @ 2025-11-11 11:50 ` Fabio Estevam 2025-11-11 12:49 ` Daniel Baluta 0 siblings, 1 reply; 19+ messages in thread From: Fabio Estevam @ 2025-11-11 11:50 UTC (permalink / raw) To: Daniel Baluta Cc: Krzysztof Kozlowski, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-11 11:50 ` Fabio Estevam @ 2025-11-11 12:49 ` Daniel Baluta 2025-11-12 8:15 ` Daniel Baluta 0 siblings, 1 reply; 19+ messages in thread From: Daniel Baluta @ 2025-11-11 12:49 UTC (permalink / raw) To: Fabio Estevam Cc: Krzysztof Kozlowski, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-11 12:49 ` Daniel Baluta @ 2025-11-12 8:15 ` Daniel Baluta 2025-11-12 9:08 ` Krzysztof Kozlowski 0 siblings, 1 reply; 19+ messages in thread From: Daniel Baluta @ 2025-11-12 8:15 UTC (permalink / raw) To: Fabio Estevam Cc: Krzysztof Kozlowski, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 8:15 ` Daniel Baluta @ 2025-11-12 9:08 ` Krzysztof Kozlowski 2025-11-12 9:14 ` Krzysztof Kozlowski 0 siblings, 1 reply; 19+ messages in thread From: Krzysztof Kozlowski @ 2025-11-12 9:08 UTC (permalink / raw) To: Daniel Baluta, Fabio Estevam Cc: Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 9:08 ` Krzysztof Kozlowski @ 2025-11-12 9:14 ` Krzysztof Kozlowski 2025-11-12 9:32 ` Daniel Baluta 0 siblings, 1 reply; 19+ messages in thread From: Krzysztof Kozlowski @ 2025-11-12 9:14 UTC (permalink / raw) To: Daniel Baluta, Fabio Estevam Cc: Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 9:14 ` Krzysztof Kozlowski @ 2025-11-12 9:32 ` Daniel Baluta 2025-11-12 9:40 ` Krzysztof Kozlowski 0 siblings, 1 reply; 19+ messages in thread From: Daniel Baluta @ 2025-11-12 9:32 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Fabio Estevam, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 9:32 ` Daniel Baluta @ 2025-11-12 9:40 ` Krzysztof Kozlowski 2025-11-12 12:35 ` Daniel Baluta 0 siblings, 1 reply; 19+ messages in thread From: Krzysztof Kozlowski @ 2025-11-12 9:40 UTC (permalink / raw) To: Daniel Baluta Cc: Fabio Estevam, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 9:40 ` Krzysztof Kozlowski @ 2025-11-12 12:35 ` Daniel Baluta 2025-11-12 14:04 ` Rogerio Pimentel 0 siblings, 1 reply; 19+ messages in thread From: Daniel Baluta @ 2025-11-12 12:35 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Fabio Estevam, Rogerio Pimentel, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo <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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 12:35 ` Daniel Baluta @ 2025-11-12 14:04 ` Rogerio Pimentel 2025-11-12 14:24 ` Krzysztof Kozlowski 0 siblings, 1 reply; 19+ messages in thread From: Rogerio Pimentel @ 2025-11-12 14:04 UTC (permalink / raw) To: Daniel Baluta Cc: Krzysztof Kozlowski, Fabio Estevam, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board 2025-11-12 14:04 ` Rogerio Pimentel @ 2025-11-12 14:24 ` Krzysztof Kozlowski 0 siblings, 0 replies; 19+ messages in thread From: Krzysztof Kozlowski @ 2025-11-12 14:24 UTC (permalink / raw) To: Rogerio Pimentel, Daniel Baluta Cc: Fabio Estevam, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel, Xiaofeng Wei, Daniel Baluta, Joseph Guo 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board 2025-11-09 21:45 [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board Rogerio Pimentel 2025-11-09 21:45 ` [PATCH v4 2/2] arm64: dts: add support for NXP " Rogerio Pimentel @ 2025-11-10 1:04 ` Rob Herring 1 sibling, 0 replies; 19+ messages in thread From: Rob Herring @ 2025-11-10 1:04 UTC (permalink / raw) To: Rogerio Pimentel Cc: krzk+dt, conor+dt, shawnguo, s.hauer, kernel, festevam, alexander.stein, dario.binacchi, marex, Markus.Niebel, y.moog, joao.goncalves, frieder.schrempf, josua, francesco.dolcini, primoz.fiser, imx, linux-arm-kernel, devicetree, linux-kernel 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2025-11-12 14:24 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-09 21:45 [PATCH v4 1/2] dt-bindings: arm: fsl: Add i.MX8MP FRDM board Rogerio Pimentel 2025-11-09 21:45 ` [PATCH v4 2/2] arm64: dts: add support for NXP " Rogerio Pimentel 2025-11-10 5:15 ` Joseph Guo 2025-11-10 19:26 ` Fabio Estevam 2025-11-11 10:22 ` Daniel Baluta 2025-11-10 20:14 ` Krzysztof Kozlowski 2025-11-10 20:12 ` Krzysztof Kozlowski 2025-11-11 8:47 ` Daniel Baluta 2025-11-11 11:50 ` Fabio Estevam 2025-11-11 12:49 ` Daniel Baluta 2025-11-12 8:15 ` Daniel Baluta 2025-11-12 9:08 ` Krzysztof Kozlowski 2025-11-12 9:14 ` Krzysztof Kozlowski 2025-11-12 9:32 ` Daniel Baluta 2025-11-12 9:40 ` Krzysztof Kozlowski 2025-11-12 12:35 ` Daniel Baluta 2025-11-12 14:04 ` Rogerio Pimentel 2025-11-12 14:24 ` Krzysztof Kozlowski 2025-11-10 1:04 ` [PATCH v4 1/2] dt-bindings: arm: fsl: Add " Rob Herring
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).