[PATCH v6 0/3] Add Radxa CM5 and IO Board

[PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

This patch series add support for the Radxa CM5 SoM and IO Board.

Changes in v6:
(Patch 1/3)
- Fix description; "Radxa CM5" is the correct name
(Patch 2/3)
- Fix #include(s)
- Include rk3588s.dtsi
- Move alias for gmac1 from io board dts
- Add Maskrom key
- Add pinctrl-* for led-0
- Add vcc_1v1_nldo_s3 regulator for pmic
- Move gmac1 (except status) from io board dts
- Fix phy-supply for gmac1
- Fix compatible for vdd_cpu_big1_s0 regulator
- Add eeprom on i2c0
- Add vdd_npu_s0 regulator for rknn
- Fix compatible for rgmii_phy1
- Add pinctrl-* and reset-* for rgmii_phy1
- Add domain-supply for pd_npu
- Add rknn_*
- Add saradc
- Fix properties in sdhci
- Move pmic from io board dts
- Fix vcc*-supply for pmic
- Add regulators in pmic
- Add tsadc
- Move vop(_mmu) from io board dts
- Trivial changes (labels, names, etc)
(Patch 3/3)
- Fix #include(s)
- Remove #include "rk3588s.dtsi"
- Fix model
- Add fan
- Add Recovery key
- Add pinctrl-* for vcc3v3_wf
- Add vcc_sysin regulator
- Add pinctrl-* for vbus5v0_typec
- Add rfkill-bt and rfkill-wlan for M.2 module
- Add sound for es8316
- Add phy-supply for combphy2_psu
- Fix power-role to "source" for fusb302
- Add rtc for hym8536
- Add audio-codec on i2c8 for es8316
- Add i2s0_8ch for es8316
- Add package_thermal for fan
- Add pinctrl-* for pcie2x1l2
- Add pwm11 for fan
- Fix properties in sdmmmc
- Add phy-supply for u2phy2_host and u2phy3_host
- Remove usb_host0_ohci
- Add pinctrl-* for usbdp_phy0
- Trivial changes (labels, names, etc)

Changes in v5:
(Patch 2/3, per Jimmy)
- Alias eMMC to mmc0
- Remove unused sdio alias
- Move gmac, hdmi0 nodes to carrier board dts
(Patch 3/3, per Jimmy)
- Enable hdmi0_sound and i2s5_8ch
- Remove redundant enablement of sdhci
- Enable usb_host2_xhci

- Tested HDMI audio

Changes in v4:
- Fixed XHCI initialization bug by changing try-power-role from source
  to sink

Changes in v3:
- Addressed YAML syntax error in dt binding (per Rob)
- Fixed whitespace issue in dts reported by checkpatch.pl
- Split base SoM and carrier board into separate patches
- Added further details about the SoM and carrier to the commit
  messages

Changes in v2:
- Added copyright header and data sheet links
- Removed non-existent property
- Sorted alphabetically
- Removed errant whitespace
- Moved status to the end of each node
- Removed pinctrl-names property from leds (indicated by CHECK_DTBS)
- Removed delays from gmac with internal delay

Link: https://lore.kernel.org/r/20250617-rk3588s-cm5-io-dts-upstream-v5-0-8d96854a5bbd@gmail.com
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
I have communicated with Joseph privately and taken ownership of
moving this forward, with his blessing. All bugs belong to me.
---
FUKAUMI Naoki (3):
  dt-bindings: arm: rockchip: Add Radxa CM5 IO Board
  arm64: dts: rockchip: Add Radxa CM5
  arm64: dts: rockchip: Add Radxa CM5 IO Board

 .../devicetree/bindings/arm/rockchip.yaml     |   7 +
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588s-radxa-cm5-io.dts     | 503 +++++++++++++++
 .../boot/dts/rockchip/rk3588s-radxa-cm5.dtsi  | 602 ++++++++++++++++++
 4 files changed, 1113 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi

-- 
2.43.0

[PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

Add device tree binding documentation for the Radxa CM5 IO Board.

Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ba61ea7436132..1829daad88ab5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -902,6 +902,13 @@ properties:
           - const: radxa,cm3i
           - const: rockchip,rk3568
 
+      - description: Radxa CM5
+        items:
+          - enum:
+              - radxa,cm5-io
+          - const: radxa,cm5
+          - const: rockchip,rk3588s
+
       - description: Radxa E20C
         items:
           - const: radxa,e20c
-- 
2.43.0

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 05/11/2025 06:13, FUKAUMI Naoki wrote:
> Add device tree binding documentation for the Radxa CM5 IO Board.
> 
> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>

Wrong DCO chain.

> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++

NAK, you just stolen ownership of an already posted patch.

Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

On 11/5/25 15:43, Krzysztof Kozlowski wrote:
> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>
>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> 
> Wrong DCO chain.
> 
>> ---
>>   Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
> 
> NAK, you just stolen ownership of an already posted patch.

Read "Changes in v6" and patches; my patches are not the same as v5.
Your reply is totally inappropriate.

> Best regards,
> Krzysztof
> 

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 05/11/2025 07:57, FUKAUMI Naoki wrote:
> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>
>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>
>> Wrong DCO chain.
>>
>>> ---
>>>   Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>
>> NAK, you just stolen ownership of an already posted patch.
> 
> Read "Changes in v6" and patches; my patches are not the same as v5.
> Your reply is totally inappropriate.

Inappropriate is taking authorship of someone's patch, because we all
expect to preserve the original authorship. That's not only basic
decency but actually a standard.

Additionally, read Joseph's reply that he wants to continue the work:
https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/

You clearly do not understand how to continue with someone's work.

It is still a NAK.

Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>
>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>
>>> Wrong DCO chain.
>>>
>>>> ---
>>>>   Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>
>>> NAK, you just stolen ownership of an already posted patch.
>>
>> Read "Changes in v6" and patches; my patches are not the same as v5.
>> Your reply is totally inappropriate.
> 
> Inappropriate is taking authorship of someone's patch, because we all
> expect to preserve the original authorship. That's not only basic
> decency but actually a standard.
> 
> Additionally, read Joseph's reply that he wants to continue the work:
> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
> 
> You clearly do not understand how to continue with someone's work.
> 
> It is still a NAK.

And I still wait for justification why you took authorship of this
patch, because to my eye you changed here nothing.

So what did you change HERE that you think you are the author now?

Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

Hi Krzysztof,

On 11/14/25 16:12, Krzysztof Kozlowski wrote:
> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>
>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>
>>>> Wrong DCO chain.
>>>>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>
>>>> NAK, you just stolen ownership of an already posted patch.
>>>
>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>> Your reply is totally inappropriate.
>>
>> Inappropriate is taking authorship of someone's patch, because we all
>> expect to preserve the original authorship. That's not only basic
>> decency but actually a standard.
>>
>> Additionally, read Joseph's reply that he wants to continue the work:
>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>
>> You clearly do not understand how to continue with someone's work.
>>
>> It is still a NAK.
> 
> And I still wait for justification why you took authorship of this
> patch, because to my eye you changed here nothing.
> 
> So what did you change HERE that you think you are the author now?

Changes in v6:
(Patch 1/3)
- Fix description; "Radxa CM5" is the correct name
(Patch 2/3)
- Fix #include(s)
- Include rk3588s.dtsi
- Move alias for gmac1 from io board dts
- Add Maskrom key
- Add pinctrl-* for led-0
- Add vcc_1v1_nldo_s3 regulator for pmic
- Move gmac1 (except status) from io board dts
- Fix phy-supply for gmac1
- Fix compatible for vdd_cpu_big1_s0 regulator
- Add eeprom on i2c0
- Add vdd_npu_s0 regulator for rknn
- Fix compatible for rgmii_phy1
- Add pinctrl-* and reset-* for rgmii_phy1
- Add domain-supply for pd_npu
- Add rknn_*
- Add saradc
- Fix properties in sdhci
- Move pmic from io board dts
- Fix vcc*-supply for pmic
- Add regulators in pmic
- Add tsadc
- Move vop(_mmu) from io board dts
- Trivial changes (labels, names, etc)
(Patch 3/3)
- Fix #include(s)
- Remove #include "rk3588s.dtsi"
- Fix model
- Add fan
- Add Recovery key
- Add pinctrl-* for vcc3v3_wf
- Add vcc_sysin regulator
- Add pinctrl-* for vbus5v0_typec
- Add rfkill-bt and rfkill-wlan for M.2 module
- Add sound for es8316
- Add phy-supply for combphy2_psu
- Fix power-role to "source" for fusb302
- Add rtc for hym8536
- Add audio-codec on i2c8 for es8316
- Add i2s0_8ch for es8316
- Add package_thermal for fan
- Add pinctrl-* for pcie2x1l2
- Add pwm11 for fan
- Fix properties in sdmmmc
- Add phy-supply for u2phy2_host and u2phy3_host
- Remove usb_host0_ohci
- Add pinctrl-* for usbdp_phy0
- Trivial changes (labels, names, etc)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4fb6b0e7851f9..f38bbb233bd2a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -880,13 +880,6 @@ properties:
            - const: radxa,cm3
            - const: rockchip,rk3566

-      - description: Radxa Compute Module 5 (CM5)
-        items:
-          - enum:
-              - radxa,cm5-io
-          - const: radxa,cm5
-          - const: rockchip,rk3588s
-
        - description: Radxa CM3 Industrial
          items:
            - enum:
@@ -894,6 +887,13 @@ properties:
            - const: radxa,cm3i
            - const: rockchip,rk3568

+      - description: Radxa CM5
+        items:
+          - enum:
+              - radxa,cm5-io
+          - const: radxa,cm5
+          - const: rockchip,rk3588s
+
        - description: Radxa E20C
          items:
            - const: radxa,e20c
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts 
b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
index 18e11a9c7f037..12fa8ba83212a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
@@ -1,23 +1,28 @@
  // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  /*
+ * Copyright (c) 2025 Radxa Computer (Shenzhen) Co., Ltd.
   * Copyright (c) 2025 Joseph Kogut <joseph.kogut@gmail.com>
   */

  /*
- * CM5 IO board data sheet
- * https://dl.radxa.com/cm5/v2200/radxa_cm5_io_v2200_schematic.pdf
+ * CM5 IO Board schematic
+ * 
https://dl.radxa.com/cm5/io_board_v2200/radxa_cm5_io_board_v2200_schematic.pdf
   */

  /dts-v1/;
-#include "rk3588s.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
  #include "rk3588s-radxa-cm5.dtsi"

  / {
-	model = "Radxa Compute Module 5 (CM5) IO Board";
+	model = "Radxa CM5 IO Board";
  	compatible = "radxa,cm5-io", "radxa,cm5", "rockchip,rk3588s";

  	aliases {
-		ethernet0 = &gmac1;
  		mmc1 = &sdmmc;
  	};

@@ -25,18 +30,40 @@ chosen {
  		stdout-path = "serial2:1500000n8";
  	};

-	hdmi-con {
+	fan: fan {
+		compatible = "pwm-fan";
+		#cooling-cells = <2>;
+		cooling-levels = <0 64 128 192 255>;
+		fan-supply = <&vcc5v0_sys>;
+		pwms = <&pwm11 0 60000 0>;
+	};
+
+	hdmi0-con {
  		compatible = "hdmi-connector";
  		type = "a";

  		port {
-			hdmi_con_in: endpoint {
+			hdmi0_con_in: endpoint {
  				remote-endpoint = <&hdmi0_out_con>;
  			};
  		};
  	};

-	vcc12v_dcin: regulator-12v0-vcc-dcin {
+	keys-1 {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-1 {
+			label = "Recovery";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	vcc12v_dcin: regulator-12v0 {
  		compatible = "regulator-fixed";
  		regulator-name = "vcc12v_dcin";
  		regulator-always-on;
@@ -45,21 +72,29 @@ vcc12v_dcin: regulator-12v0-vcc-dcin {
  		regulator-max-microvolt = <12000000>;
  	};

-	vcc5v0_host: vcc5v0-host-regulator {
+	vcc3v3_wf: regulator-3v3 {
  		compatible = "regulator-fixed";
-		regulator-name = "vcc5v0_host";
-		regulator-boot-on;
-		regulator-always-on;
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
  		enable-active-high;
-		gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio1 RK_PD3 GPIO_ACTIVE_HIGH>;
  		pinctrl-names = "default";
-		pinctrl-0 = <&vcc5v0_host_en>;
+		pinctrl-0 = <&wifi_pwr_en>;
+		regulator-name = "vcc3v3_wf";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_sysin: regulator-4v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sysin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <4000000>;
+		regulator-max-microvolt = <4000000>;
  		vin-supply = <&vcc5v0_sys>;
  	};

-	vcc5v0_sys: regulator-5v0-sys {
+	vcc5v0_sys: vcc5v0_usb: regulator-5v0-0 {
  		compatible = "regulator-fixed";
  		regulator-name = "vcc5v0_sys";
  		regulator-always-on;
@@ -69,43 +104,55 @@ vcc5v0_sys: regulator-5v0-sys {
  		vin-supply = <&vcc12v_dcin>;
  	};

-	vbus5v0_typec: vbus5v0-typec {
+	vcc5v0_usb1: regulator-5v0-1 {
  		compatible = "regulator-fixed";
-		regulator-name = "vbus5v0_typec";
-		gpio = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&vbus5v0_typec_en>;
  		enable-active-high;
+		gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren_h>;
+		regulator-name = "vcc5v0_usb1";
  		regulator-min-microvolt = <5000000>;
  		regulator-max-microvolt = <5000000>;
-		vin-supply = <&vcc5v0_sys>;
+		vin-supply = <&vcc5v0_usb>;
  	};

-	vcc3v3_pcie: regulator-3v3-vcc-pcie {
+	vbus5v0_typec: regulator-5v0-2 {
  		compatible = "regulator-fixed";
-		regulator-name = "vcc3v3_pcie2x1l0";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
  		enable-active-high;
-		regulator-boot-on;
-		regulator-always-on;
-		gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_HIGH>;
-		startup-delay-us = <50000>;
+		gpio = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren_h>;
+		regulator-name = "vbus5v0_typec";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
  		vin-supply = <&vcc5v0_sys>;
  	};

-	vcc_3v3_s0: pldo-reg4 {
-		compatible = "regulator-fixed";
-		regulator-name = "vcc_3v3_s0";
-		regulator-always-on;
-		regulator-boot-on;
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		regulator-ramp-delay = <12500>;
+	rfkill-bt {
+		compatible = "rfkill-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&host_wake_bt_h>;
+		radio-type = "bluetooth";
+		shutdown-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+	};

-		regulator-state-mem {
-			regulator-off-in-suspend;
-		};
+	rfkill-wlan {
+		compatible = "rfkill-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_reg_on_h>;
+		radio-type = "wlan";
+		shutdown-gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+	};
+
+	sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+		dais = <&i2s0_8ch_p0>;
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
  	};
  };

@@ -114,21 +161,11 @@ &combphy0_ps {
  };

  &combphy2_psu {
+	phy-supply = <&vcc5v0_usb1>;
  	status = "okay";
  };

  &gmac1 {
-	clock_in_out = "output";
-	phy-handle = <&rgmii_phy1>;
-	phy-mode = "rgmii-id";
-	phy-supply = <&vcc_3v3_s0>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&gmac1_miim
-		     &gmac1_tx_bus2
-		     &gmac1_rx_bus2
-		     &gmac1_rgmii_clk
-		     &gmac1_rgmii_bus
-		     &gmac1_clkinout>;
  	status = "okay";
  };

@@ -144,7 +181,7 @@ hdmi0_in_vp0: endpoint {

  &hdmi0_out {
  	hdmi0_out_con: endpoint {
-		remote-endpoint = <&hdmi_con_in>;
+		remote-endpoint = <&hdmi0_con_in>;
  	};
  };

@@ -161,24 +198,24 @@ &i2c6 {
  	pinctrl-0 = <&i2c6m3_xfer>;
  	status = "okay";

-	fusb302: usb-typec@22 {
+	usb-typec@22 {
  		compatible = "fcs,fusb302";
  		reg = <0x22>;
  		interrupt-parent = <&gpio0>;
  		interrupts = <RK_PC4 IRQ_TYPE_LEVEL_LOW>;
  		pinctrl-names = "default";
-		pinctrl-0 = <&usbc0_int>;
+		pinctrl-0 = <&cc_int0_l>;
  		vbus-supply = <&vbus5v0_typec>;

  		connector {
  			compatible = "usb-c-connector";
  			data-role = "dual";
  			label = "USB-C";
-			power-role = "dual";
-			try-power-role = "sink";
-			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
-			sink-pdos = <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
-			op-sink-microwatt = <1000000>;
+			/* fusb302 supports PD Rev 2.0 Ver 1.2 */
+			pd-revision = /bits/ 8 <0x2 0x0 0x1 0x2>;
+			power-role = "source";
+			source-pdos =
+				<PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;

  			ports {
  				#address-cells = <1>;
@@ -186,205 +223,194 @@ ports {

  				port@0 {
  					reg = <0>;
-					usbc0_orientation_switch: endpoint {
-						remote-endpoint = <&usbdp_phy0_orientation_switch>;
+
+					usbc0_hs: endpoint {
+						remote-endpoint = <&usb_host0_xhci_to_usbc0>;
  					};
  				};

  				port@1 {
  					reg = <1>;
-					usbc0_role_switch: endpoint {
-						remote-endpoint = <&usb_host0_xhci_role_switch>;
+
+					usbc0_ss: endpoint {
+						remote-endpoint = <&usbdp_phy0_ss>;
  					};
  				};

  				port@2 {
  					reg = <2>;
-					usbc0_dp_altmode_mux: endpoint {
-						remote-endpoint = <&usbdp_phy0_dp_altmode_mux>;
+
+					usbc0_sbu: endpoint {
+						remote-endpoint = <&usbdp_phy0_sbu>;
  					};
  				};
  			};
  		};
  	};
-};

-&i2s5_8ch {
-	status = "okay";
+	rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-output-names = "rtc_32k_in";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int_l>;
+		wakeup-source;
+	};
  };

-&pcie2x1l2 {
-	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
-	vpcie3v3-supply = <&vcc3v3_pcie>;
+&i2c8 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c8m2_xfer>;
  	status = "okay";
-};

-&pinctrl {
-	fusb302 {
-		vbus5v0_typec_en: vbus5v0-typec-en {
-			rockchip,pins = <0 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
+	audio-codec@11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		#sound-dai-cells = <0>;

-		usbc0_int: usbc0-int {
-			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_up>;
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
  		};
  	};
+};

-	usb {
-		vcc5v0_host_en: vcc5v0-host-en {
-			rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+&i2s0_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
  		};
  	};
  };

-&sdmmc {
-	bus-width = <4>;
-	cap-mmc-highspeed;
-	cap-sd-highspeed;
-	disable-wp;
-	max-frequency = <200000000>;
-	no-sdio;
-	no-mmc;
-	sd-uhs-sdr104;
-	pinctrl-names = "default";
-	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_det>;
-	vmmc-supply = <&vcc_3v3_s3>;
-	vqmmc-supply = <&vccio_sd_s0>;
+&i2s5_8ch {
  	status = "okay";
  };

-&spi2 {
-	assigned-clocks = <&cru CLK_SPI2>;
-	assigned-clock-rates = <200000000>;
-	num-cs = <1>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
-	status = "okay";
+&package_thermal {
+	polling-delay = <1000>;

-	pmic@0 {
-		compatible = "rockchip,rk806";
-		reg = <0x0>;
-		interrupt-parent = <&gpio0>;
-		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
-			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
-		spi-max-frequency = <1000000>;
-		system-power-controller;
-
-		vcc1-supply = <&vcc5v0_sys>;
-		vcc2-supply = <&vcc5v0_sys>;
-		vcc3-supply = <&vcc5v0_sys>;
-		vcc4-supply = <&vcc5v0_sys>;
-		vcc5-supply = <&vcc5v0_sys>;
-		vcc6-supply = <&vcc5v0_sys>;
-		vcc7-supply = <&vcc5v0_sys>;
-		vcc8-supply = <&vcc5v0_sys>;
-		vcc9-supply = <&vcc5v0_sys>;
-		vcc10-supply = <&vcc5v0_sys>;
-		vcc11-supply = <&vcc_2v0_pldo_s3>;
-		vcc12-supply = <&vcc5v0_sys>;
-		vcc13-supply = <&vdd2_ddr_s3>;
-		vcc14-supply = <&vdd2_ddr_s3>;
-		vcca-supply = <&vcc5v0_sys>;
-
-		gpio-controller;
-		#gpio-cells = <2>;
-
-		rk806_dvs1_null: dvs1-null-pins {
-			pins = "gpio_pwrctrl1";
-			function = "pin_fun0";
+	trips {
+		package_fan0: package-fan0 {
+			hysteresis = <2000>;
+			temperature = <55000>;
+			type = "active";
  		};

-		rk806_dvs2_null: dvs2-null-pins {
-			pins = "gpio_pwrctrl2";
-			function = "pin_fun0";
+		package_fan1: package-fan1 {
+			hysteresis = <2000>;
+			temperature = <65000>;
+			type = "active";
  		};
+	};

-		rk806_dvs3_null: dvs3-null-pins {
-			pins = "gpio_pwrctrl3";
-			function = "pin_fun0";
+	cooling-maps {
+		map0 {
+			cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+			trip = <&package_fan0>;
  		};

-		regulators {
-			vdd_gpu_s0: dcdc-reg1 {
-				regulator-name = "vdd_gpu_s0";
-				regulator-boot-on;
-				regulator-enable-ramp-delay = <400>;
-				regulator-min-microvolt = <550000>;
-				regulator-max-microvolt = <950000>;
-				regulator-ramp-delay = <12500>;
-
-				regulator-state-mem {
-					regulator-off-in-suspend;
-				};
-			};
+		map1 {
+			cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+			trip = <&package_fan1>;
+		};
+	};
+};

-			vdd_cpu_lit_s0: dcdc-reg2 {
-				regulator-name = "vdd_cpu_lit_s0";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <550000>;
-				regulator-max-microvolt = <950000>;
-				regulator-ramp-delay = <12500>;
+&pcie2x1l2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie20x1_2_perstn_m0>;
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_wf>;
+	status = "okay";
+};

-				regulator-state-mem {
-					regulator-off-in-suspend;
-				};
-			};
+&pinctrl {
+	pcie {
+		pcie20x1_2_perstn_m0: pcie20x1-2-perstn-m0 {
+			rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};

-			vccio_sd_s0: pldo-reg5 {
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <3300000>;
-				regulator-name = "vccio_sd_s0";
+		wifi_pwr_en: wifi-pwr-en {
+			rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};

-				regulator-state-mem {
-					regulator-off-in-suspend;
-				};
-			};
+	rfkill {
+		bt_reg_on_h: bt-reg-on-h {
+			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};

-			vdd2_ddr_s3: dcdc-reg6 {
-				regulator-name = "vdd2_ddr_s3";
-				regulator-always-on;
-				regulator-boot-on;
+		host_wake_bt_h: host-wake-bt-h {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};

-				regulator-state-mem {
-					regulator-on-in-suspend;
-				};
-			};
+	rtc {
+		rtc_int_l: rtc-int-l {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};

-			vcc_2v0_pldo_s3: dcdc-reg7 {
-				regulator-name = "vdd_2v0_pldo_s3";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <2000000>;
-				regulator-max-microvolt = <2000000>;
-				regulator-ramp-delay = <12500>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <2000000>;
-				};
-			};
+	usb {
+		cc_int0_l: cc-int0-l {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_host_pwren_h: usb-host-pwren-h {
+			rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};

-			vcc_3v3_s3: dcdc-reg8 {
-				regulator-name = "vcc_3v3_s3";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
+		usbc_sbu_dc: usbc-sbu-dc {
+			rockchip,pins = <3 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>,
+					<3 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};

-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <3300000>;
-				};
-			};
+		typec5v_pwren_h: typec5v-pwren-h {
+			rockchip,pins = <0 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
  		};
  	};
  };

+&pwm11 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm11m3_pins>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	no-sdio;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
  &u2phy0 {
  	status = "okay";
  };
@@ -398,6 +424,7 @@ &u2phy2 {
  };

  &u2phy2_host {
+	phy-supply = <&vcc5v0_usb1>;
  	status = "okay";
  };

@@ -406,6 +433,7 @@ &u2phy3 {
  };

  &u2phy3_host {
+	phy-supply = <&vcc5v0_usb1>;
  	status = "okay";
  };

@@ -419,18 +447,13 @@ &usb_host0_ehci {
  	status = "okay";
  };

-&usb_host0_ohci {
-	status = "okay";
-};
-
  &usb_host0_xhci {
-	dr_mode = "otg";
  	usb-role-switch;
  	status = "okay";

  	port {
-		usb_host0_xhci_role_switch: endpoint {
-			remote-endpoint = <&usbc0_role_switch>;
+		usb_host0_xhci_to_usbc0: endpoint {
+			remote-endpoint = <&usbc0_hs>;
  		};
  	};
  };
@@ -450,6 +473,8 @@ &usb_host2_xhci {
  &usbdp_phy0 {
  	mode-switch;
  	orientation-switch;
+	pinctrl-names = "default";
+	pinctrl-0 = <&usbc_sbu_dc>;
  	sbu1-dc-gpios = <&gpio3 RK_PC4 GPIO_ACTIVE_HIGH>;
  	sbu2-dc-gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
  	status = "okay";
@@ -458,26 +483,18 @@ port {
  		#address-cells = <1>;
  		#size-cells = <0>;

-		usbdp_phy0_orientation_switch: endpoint@0 {
+		usbdp_phy0_ss: endpoint@0 {
  			reg = <0>;
-			remote-endpoint = <&usbc0_orientation_switch>;
+			remote-endpoint = <&usbc0_ss>;
  		};

-		usbdp_phy0_dp_altmode_mux: endpoint@1 {
+		usbdp_phy0_sbu: endpoint@1 {
  			reg = <1>;
-			remote-endpoint = <&usbc0_dp_altmode_mux>;
+			remote-endpoint = <&usbc0_sbu>;
  		};
  	};
  };

-&vop {
-	status = "okay";
-};
-
-&vop_mmu {
-	status = "okay";
-};
-
  &vp0 {
  	vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
  		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
index 6410ea5255dc7..f2da73126c1fe 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
@@ -1,36 +1,67 @@
  // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  /*
+ * Copyright (c) 2025 Radxa Computer (Shenzhen) Co., Ltd.
   * Copyright (c) 2025 Joseph Kogut <joseph.kogut@gmail.com>
   */

  /*
- * CM5 data sheet
+ * CM5 schematic
   * https://dl.radxa.com/cm5/v2210/radxa_cm5_v2210_schematic.pdf
   */

+/dts-v1/;
+
  #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
  #include <dt-bindings/leds/common.h>
-#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588s.dtsi"

  / {
  	compatible = "radxa,cm5", "rockchip,rk3588s";

  	aliases {
+		ethernet0 = &gmac1;
  		mmc0 = &sdhci;
  	};

-	leds {
+	keys-0 {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-0 {
+			label = "Maskrom";
+			linux,code = <KEY_SETUP>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	leds-0 {
  		compatible = "gpio-leds";

-		led_sys: led-0 {
+		led-0 {
  			color = <LED_COLOR_ID_BLUE>;
  			default-state = "on";
-			function = LED_FUNCTION_HEARTBEAT;
+			function = LED_FUNCTION_STATUS;
  			gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
  			linux,default-trigger = "heartbeat";
+			pinctrl-names = "default";
+			pinctrl-0 = <&gpio4_b4>;
  		};
  	};
+
+	vcc_1v1_nldo_s3: regulator-1v1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc_sysin>;
+	};
  };

  &cpu_b0 {
@@ -65,6 +96,20 @@ &cpu_l3 {
  	cpu-supply = <&vdd_cpu_lit_s0>;
  };

+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-id";
+	phy-supply = <&vcc_3v3_s3>;
+	pinctrl-0 = <&gmac1_miim
+		     &gmac1_tx_bus2
+		     &gmac1_rx_bus2
+		     &gmac1_rgmii_clk
+		     &gmac1_rgmii_bus
+		     &gmac1_clkinout>;
+	pinctrl-names = "default";
+};
+
  &gpu {
  	mali-supply = <&vdd_gpu_s0>;
  	status = "okay";
@@ -85,7 +130,7 @@ vdd_cpu_big0_s0: regulator@42 {
  		regulator-min-microvolt = <550000>;
  		regulator-max-microvolt = <1050000>;
  		regulator-ramp-delay = <2300>;
-		vin-supply = <&vcc5v0_sys>;
+		vin-supply = <&vcc_sysin>;

  		regulator-state-mem {
  			regulator-off-in-suspend;
@@ -93,7 +138,7 @@ regulator-state-mem {
  	};

  	vdd_cpu_big1_s0: regulator@43 {
-		compatible = "rockchip,rk8602";
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
  		reg = <0x43>;
  		fcs,suspend-voltage-selector = <1>;
  		regulator-name = "vdd_cpu_big1_s0";
@@ -102,7 +147,36 @@ vdd_cpu_big1_s0: regulator@43 {
  		regulator-min-microvolt = <550000>;
  		regulator-max-microvolt = <1050000>;
  		regulator-ramp-delay = <2300>;
-		vin-supply = <&vcc5v0_sys>;
+		vin-supply = <&vcc_sysin>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	eeprom@50 {
+		compatible = "belling,bl24c16a", "atmel,24c16";
+		reg = <0x50>;
+		pagesize = <16>;
+		read-only;
+		vcc-supply = <&vcc_3v3_s3>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc_sysin>;

  		regulator-state-mem {
  			regulator-off-in-suspend;
@@ -111,9 +185,14 @@ regulator-state-mem {
  };

  &mdio1 {
-	rgmii_phy1: phy@1 {
-		compatible = "ethernet-phy-ieee802.3-c22";
-		reg = <0x1>;
+	rgmii_phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-id001c.c916";
+		reg = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac1_rstn>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_LOW>;
  	};
  };

@@ -121,15 +200,403 @@ &pd_gpu {
  	domain-supply = <&vdd_gpu_s0>;
  };

+&pd_npu {
+	domain-supply = <&vdd_npu_s0>;
+};
+
+&pinctrl {
+	ethernet {
+		gmac1_rstn: gmac1-rstn {
+			rockchip,pins = <3 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		gpio4_b4: gpio4-b4 {
+			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&rknn_core_0 {
+	npu-supply = <&vdd_npu_s0>;
+	sram-supply = <&vdd_npu_s0>;
+	status = "okay";
+};
+
+&rknn_core_1 {
+	npu-supply = <&vdd_npu_s0>;
+	sram-supply = <&vdd_npu_s0>;
+	status = "okay";
+};
+
+&rknn_core_2 {
+	npu-supply = <&vdd_npu_s0>;
+	sram-supply = <&vdd_npu_s0>;
+	status = "okay";
+};
+
+&rknn_mmu_0 {
+	status = "okay";
+};
+
+&rknn_mmu_1 {
+	status = "okay";
+};
+
+&rknn_mmu_2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca_1v8_s0>;
+	status = "okay";
+};
+
  &sdhci {
  	bus-width = <8>;
-	no-sdio;
-	no-sd;
-	non-removable;
-	max-frequency = <200000000>;
+	cap-mmc-highspeed;
  	mmc-hs400-1_8v;
  	mmc-hs400-enhanced-strobe;
-	mmc-hs200-1_8v;
+	no-sd;
+	no-sdio;
+	non-removable;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vcc_1v8_s3>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic@0 {
+		compatible = "rockchip,rk806";
+		reg = <0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+		system-power-controller;
+
+		vcc1-supply = <&vcc_sysin>;
+		vcc2-supply = <&vcc_sysin>;
+		vcc3-supply = <&vcc_sysin>;
+		vcc4-supply = <&vcc_sysin>;
+		vcc5-supply = <&vcc_sysin>;
+		vcc6-supply = <&vcc_sysin>;
+		vcc7-supply = <&vcc_sysin>;
+		vcc8-supply = <&vcc_sysin>;
+		vcc9-supply = <&vcc_sysin>;
+		vcc10-supply = <&vcc_sysin>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc_sysin>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc_sysin>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: dcdc-reg1 {
+				regulator-name = "vdd_gpu_s0";
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_logic_s0: dcdc-reg3 {
+				regulator-name = "vdd_logic_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <800000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vcc_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s0: vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg1 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcca_1v8_s0: pldo-reg2 {
+				regulator-name = "vcca_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdda_1v2_s0: pldo-reg3 {
+				regulator-name = "vdda_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_3v3_s0: pldo-reg4 {
+				regulator-name = "vcca_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo-reg6 {
+				regulator-name = "pldo_reg6";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdda_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdda_0v75_s0: nldo-reg3 {
+				regulator-name = "vdda_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_0v85_s0: nldo-reg4 {
+				regulator-name = "vdda_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			hdmi_vdda0v85_s0: nldo-reg5 {
+				regulator-name = "hdmi_vdda0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+	status = "okay";
+};
+
+&vop {
  	status = "okay";
  };

+&vop_mmu {
+	status = "okay";
+};

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Best regards,
> Krzysztof
> 

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 14/11/2025 08:37, FUKAUMI Naoki wrote:
> Hi Krzysztof,
> 
> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>>
>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>
>>>>> Wrong DCO chain.
>>>>>
>>>>>> ---
>>>>>>    Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>>
>>>>> NAK, you just stolen ownership of an already posted patch.
>>>>
>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>>> Your reply is totally inappropriate.
>>>
>>> Inappropriate is taking authorship of someone's patch, because we all
>>> expect to preserve the original authorship. That's not only basic
>>> decency but actually a standard.
>>>
>>> Additionally, read Joseph's reply that he wants to continue the work:
>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>>
>>> You clearly do not understand how to continue with someone's work.
>>>
>>> It is still a NAK.
>>
>> And I still wait for justification why you took authorship of this
>> patch, because to my eye you changed here nothing.
>>
>> So what did you change HERE that you think you are the author now?
> 
> Changes in v6:
> (Patch 1/3)
> - Fix description; "Radxa CM5" is the correct name

HERE, in this patch. Don't paste me hundreds of unrelated code. Write
concise and precise answers/comments.

Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

On 11/14/25 16:42, Krzysztof Kozlowski wrote:
> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
>> Hi Krzysztof,
>>
>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>>>
>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>
>>>>>> Wrong DCO chain.
>>>>>>
>>>>>>> ---
>>>>>>>     Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>>>
>>>>>> NAK, you just stolen ownership of an already posted patch.
>>>>>
>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>>>> Your reply is totally inappropriate.
>>>>
>>>> Inappropriate is taking authorship of someone's patch, because we all
>>>> expect to preserve the original authorship. That's not only basic
>>>> decency but actually a standard.
>>>>
>>>> Additionally, read Joseph's reply that he wants to continue the work:
>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>>>
>>>> You clearly do not understand how to continue with someone's work.
>>>>
>>>> It is still a NAK.
>>>
>>> And I still wait for justification why you took authorship of this
>>> patch, because to my eye you changed here nothing.
>>>
>>> So what did you change HERE that you think you are the author now?
>>
>> Changes in v6:
>> (Patch 1/3)
>> - Fix description; "Radxa CM5" is the correct name
> 
> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
> concise and precise answers/comments.

https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/

| By the way, at some point I switched from "continuing your work" to
| "recreating a new one based on my current work." The results of my
| current work(*3) have changed significantly.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Best regards,
> Krzysztof
> 

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 14/11/2025 08:47, FUKAUMI Naoki wrote:
> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
>>> Hi Krzysztof,
>>>
>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>>>>
>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>>
>>>>>>> Wrong DCO chain.
>>>>>>>
>>>>>>>> ---
>>>>>>>>     Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>>>>
>>>>>>> NAK, you just stolen ownership of an already posted patch.
>>>>>>
>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>>>>> Your reply is totally inappropriate.
>>>>>
>>>>> Inappropriate is taking authorship of someone's patch, because we all
>>>>> expect to preserve the original authorship. That's not only basic
>>>>> decency but actually a standard.
>>>>>
>>>>> Additionally, read Joseph's reply that he wants to continue the work:
>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>>>>
>>>>> You clearly do not understand how to continue with someone's work.
>>>>>
>>>>> It is still a NAK.
>>>>
>>>> And I still wait for justification why you took authorship of this
>>>> patch, because to my eye you changed here nothing.
>>>>
>>>> So what did you change HERE that you think you are the author now?
>>>
>>> Changes in v6:
>>> (Patch 1/3)
>>> - Fix description; "Radxa CM5" is the correct name
>>
>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
>> concise and precise answers/comments.
> 
> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
> 
> | By the way, at some point I switched from "continuing your work" to
> | "recreating a new one based on my current work." The results of my
> | current work(*3) have changed significantly.

So next time I will take your patch, your code, say "I recreated it" and
submit under my authorship and for you it is fine?

Please take Joseph's patch instead. Read submitting patches doc to
understand which one more tag has to be added when sending somoene
else's work.

In the future, I sincerely suggest avoiding re-creating people's work
but building on top, because you just duplicate the effort.

Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

On 11/14/25 16:51, Krzysztof Kozlowski wrote:
> On 14/11/2025 08:47, FUKAUMI Naoki wrote:
>> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
>>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
>>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>>>>>
>>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>>>
>>>>>>>> Wrong DCO chain.
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>      Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>>>>>
>>>>>>>> NAK, you just stolen ownership of an already posted patch.
>>>>>>>
>>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>>>>>> Your reply is totally inappropriate.
>>>>>>
>>>>>> Inappropriate is taking authorship of someone's patch, because we all
>>>>>> expect to preserve the original authorship. That's not only basic
>>>>>> decency but actually a standard.
>>>>>>
>>>>>> Additionally, read Joseph's reply that he wants to continue the work:
>>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>>>>>
>>>>>> You clearly do not understand how to continue with someone's work.
>>>>>>
>>>>>> It is still a NAK.
>>>>>
>>>>> And I still wait for justification why you took authorship of this
>>>>> patch, because to my eye you changed here nothing.
>>>>>
>>>>> So what did you change HERE that you think you are the author now?
>>>>
>>>> Changes in v6:
>>>> (Patch 1/3)
>>>> - Fix description; "Radxa CM5" is the correct name
>>>
>>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
>>> concise and precise answers/comments.
>>
>> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
>>
>> | By the way, at some point I switched from "continuing your work" to
>> | "recreating a new one based on my current work." The results of my
>> | current work(*3) have changed significantly.
> 
> So next time I will take your patch, your code, say "I recreated it" and
> submit under my authorship and for you it is fine?

Regarding CM5 patches, I'm fine.

> Please take Joseph's patch instead. Read submitting patches doc to
> understand which one more tag has to be added when sending somoene
> else's work.
> 
> In the future, I sincerely suggest avoiding re-creating people's work
> but building on top, because you just duplicate the effort.

I understand that you don't understand how I made efforts to build my 
work on top of Joseph's patches.

Thank you for your attention.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Best regards,
> Krzysztof
> 

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

On Friday, November 14, 2025 09:24 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 11/14/25 16:51, Krzysztof Kozlowski wrote:
> > On 14/11/2025 08:47, FUKAUMI Naoki wrote:
> >> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
> >>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
> >>>> Hi Krzysztof,
> >>>>
> >>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
> >>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
> >>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
> >>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
> >>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
> >>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
> >>>>>>>>>
> >>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
> >>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> >>>>>>>>
> >>>>>>>> Wrong DCO chain.
> >>>>>>>>
> >>>>>>>>> ---
> >>>>>>>>>      Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
> >>>>>>>>
> >>>>>>>> NAK, you just stolen ownership of an already posted patch.
> >>>>>>>
> >>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
> >>>>>>> Your reply is totally inappropriate.
> >>>>>>
> >>>>>> Inappropriate is taking authorship of someone's patch, because we all
> >>>>>> expect to preserve the original authorship. That's not only basic
> >>>>>> decency but actually a standard.
> >>>>>>
> >>>>>> Additionally, read Joseph's reply that he wants to continue the work:
> >>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
> >>>>>>
> >>>>>> You clearly do not understand how to continue with someone's work.
> >>>>>>
> >>>>>> It is still a NAK.
> >>>>>
> >>>>> And I still wait for justification why you took authorship of this
> >>>>> patch, because to my eye you changed here nothing.
> >>>>>
> >>>>> So what did you change HERE that you think you are the author now?
> >>>>
> >>>> Changes in v6:
> >>>> (Patch 1/3)
> >>>> - Fix description; "Radxa CM5" is the correct name
> >>>
> >>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
> >>> concise and precise answers/comments.
> >>
> >> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
> >>
> >> | By the way, at some point I switched from "continuing your work" to
> >> | "recreating a new one based on my current work." The results of my
> >> | current work(*3) have changed significantly.
> > 
> > So next time I will take your patch, your code, say "I recreated it" and
> > submit under my authorship and for you it is fine?
> 
> Regarding CM5 patches, I'm fine.
> 
> > Please take Joseph's patch instead. Read submitting patches doc to
> > understand which one more tag has to be added when sending somoene
> > else's work.
> > 
> > In the future, I sincerely suggest avoiding re-creating people's work
> > but building on top, because you just duplicate the effort.
> 
> I understand that you don't understand how I made efforts to build my 
> work on top of Joseph's patches.

Maybe a solution for this huge mess could be that Naoki submits
unmodified patches from Joseph first, using the standard procedure
for that, and then the additional patch(es) that improve Joseph's
work?  All that in the same series.

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Heiko Stübner]

Am Freitag, 14. November 2025, 09:32:29 Mitteleuropäische Normalzeit schrieb Dragan Simic:
> On Friday, November 14, 2025 09:24 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> > On 11/14/25 16:51, Krzysztof Kozlowski wrote:
> > > On 14/11/2025 08:47, FUKAUMI Naoki wrote:
> > >> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
> > >>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
> > >>>> Hi Krzysztof,
> > >>>>
> > >>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
> > >>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
> > >>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
> > >>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
> > >>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
> > >>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
> > >>>>>>>>>
> > >>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
> > >>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> > >>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> > >>>>>>>>
> > >>>>>>>> Wrong DCO chain.
> > >>>>>>>>
> > >>>>>>>>> ---
> > >>>>>>>>>      Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
> > >>>>>>>>
> > >>>>>>>> NAK, you just stolen ownership of an already posted patch.
> > >>>>>>>
> > >>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
> > >>>>>>> Your reply is totally inappropriate.
> > >>>>>>
> > >>>>>> Inappropriate is taking authorship of someone's patch, because we all
> > >>>>>> expect to preserve the original authorship. That's not only basic
> > >>>>>> decency but actually a standard.
> > >>>>>>
> > >>>>>> Additionally, read Joseph's reply that he wants to continue the work:
> > >>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
> > >>>>>>
> > >>>>>> You clearly do not understand how to continue with someone's work.
> > >>>>>>
> > >>>>>> It is still a NAK.
> > >>>>>
> > >>>>> And I still wait for justification why you took authorship of this
> > >>>>> patch, because to my eye you changed here nothing.
> > >>>>>
> > >>>>> So what did you change HERE that you think you are the author now?
> > >>>>
> > >>>> Changes in v6:
> > >>>> (Patch 1/3)
> > >>>> - Fix description; "Radxa CM5" is the correct name
> > >>>
> > >>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
> > >>> concise and precise answers/comments.
> > >>
> > >> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
> > >>
> > >> | By the way, at some point I switched from "continuing your work" to
> > >> | "recreating a new one based on my current work." The results of my
> > >> | current work(*3) have changed significantly.
> > > 
> > > So next time I will take your patch, your code, say "I recreated it" and
> > > submit under my authorship and for you it is fine?
> > 
> > Regarding CM5 patches, I'm fine.
> > 
> > > Please take Joseph's patch instead. Read submitting patches doc to
> > > understand which one more tag has to be added when sending somoene
> > > else's work.
> > > 
> > > In the future, I sincerely suggest avoiding re-creating people's work
> > > but building on top, because you just duplicate the effort.
> > 
> > I understand that you don't understand how I made efforts to build my 
> > work on top of Joseph's patches.
> 
> Maybe a solution for this huge mess could be that Naoki submits
> unmodified patches from Joseph first, using the standard procedure
> for that, and then the additional patch(es) that improve Joseph's
> work?  All that in the same series.

There is also Co-developed-by as an option.

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

Hello Heiko,

On Friday, November 14, 2025 11:08 CET, Heiko Stübner <heiko@sntech.de> wrote:
> Am Freitag, 14. November 2025, 09:32:29 Mitteleuropäische Normalzeit schrieb Dragan Simic:
> > On Friday, November 14, 2025 09:24 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> > > On 11/14/25 16:51, Krzysztof Kozlowski wrote:
> > > > On 14/11/2025 08:47, FUKAUMI Naoki wrote:
> > > >> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
> > > >>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
> > > >>>> Hi Krzysztof,
> > > >>>>
> > > >>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
> > > >>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
> > > >>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
> > > >>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
> > > >>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
> > > >>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
> > > >>>>>>>>>
> > > >>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
> > > >>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> > > >>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> > > >>>>>>>>
> > > >>>>>>>> Wrong DCO chain.
> > > >>>>>>>>
> > > >>>>>>>>> ---
> > > >>>>>>>>>      Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
> > > >>>>>>>>
> > > >>>>>>>> NAK, you just stolen ownership of an already posted patch.
> > > >>>>>>>
> > > >>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
> > > >>>>>>> Your reply is totally inappropriate.
> > > >>>>>>
> > > >>>>>> Inappropriate is taking authorship of someone's patch, because we all
> > > >>>>>> expect to preserve the original authorship. That's not only basic
> > > >>>>>> decency but actually a standard.
> > > >>>>>>
> > > >>>>>> Additionally, read Joseph's reply that he wants to continue the work:
> > > >>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
> > > >>>>>>
> > > >>>>>> You clearly do not understand how to continue with someone's work.
> > > >>>>>>
> > > >>>>>> It is still a NAK.
> > > >>>>>
> > > >>>>> And I still wait for justification why you took authorship of this
> > > >>>>> patch, because to my eye you changed here nothing.
> > > >>>>>
> > > >>>>> So what did you change HERE that you think you are the author now?
> > > >>>>
> > > >>>> Changes in v6:
> > > >>>> (Patch 1/3)
> > > >>>> - Fix description; "Radxa CM5" is the correct name
> > > >>>
> > > >>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
> > > >>> concise and precise answers/comments.
> > > >>
> > > >> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
> > > >>
> > > >> | By the way, at some point I switched from "continuing your work" to
> > > >> | "recreating a new one based on my current work." The results of my
> > > >> | current work(*3) have changed significantly.
> > > > 
> > > > So next time I will take your patch, your code, say "I recreated it" and
> > > > submit under my authorship and for you it is fine?
> > > 
> > > Regarding CM5 patches, I'm fine.
> > > 
> > > > Please take Joseph's patch instead. Read submitting patches doc to
> > > > understand which one more tag has to be added when sending somoene
> > > > else's work.
> > > > 
> > > > In the future, I sincerely suggest avoiding re-creating people's work
> > > > but building on top, because you just duplicate the effort.
> > > 
> > > I understand that you don't understand how I made efforts to build my 
> > > work on top of Joseph's patches.
> > 
> > Maybe a solution for this huge mess could be that Naoki submits
> > unmodified patches from Joseph first, using the standard procedure
> > for that, and then the additional patch(es) that improve Joseph's
> > work?  All that in the same series.
> 
> There is also Co-developed-by as an option.

Ah, that's what the above-described option #1 involves, but it also 
raises some possible concerns, described in one of my responses. [1]

[1] https://lore.kernel.org/linux-rockchip/c01b756a-73ea-3d0d-44b9-6ce8a535a103@manjaro.org/

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 14/11/2025 11:12, Dragan Simic wrote:
> Hello Heiko,
> 
> On Friday, November 14, 2025 11:08 CET, Heiko Stübner <heiko@sntech.de> wrote:
>> Am Freitag, 14. November 2025, 09:32:29 Mitteleuropäische Normalzeit schrieb Dragan Simic:
>>> On Friday, November 14, 2025 09:24 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>> On 11/14/25 16:51, Krzysztof Kozlowski wrote:
>>>>> On 14/11/2025 08:47, FUKAUMI Naoki wrote:
>>>>>> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
>>>>>>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
>>>>>>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>>>>>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>>>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>>>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>> Wrong DCO chain.
>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>      Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>>>>>>>>>
>>>>>>>>>>>> NAK, you just stolen ownership of an already posted patch.
>>>>>>>>>>>
>>>>>>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>>>>>>>>>> Your reply is totally inappropriate.
>>>>>>>>>>
>>>>>>>>>> Inappropriate is taking authorship of someone's patch, because we all
>>>>>>>>>> expect to preserve the original authorship. That's not only basic
>>>>>>>>>> decency but actually a standard.
>>>>>>>>>>
>>>>>>>>>> Additionally, read Joseph's reply that he wants to continue the work:
>>>>>>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>>>>>>>>>
>>>>>>>>>> You clearly do not understand how to continue with someone's work.
>>>>>>>>>>
>>>>>>>>>> It is still a NAK.
>>>>>>>>>
>>>>>>>>> And I still wait for justification why you took authorship of this
>>>>>>>>> patch, because to my eye you changed here nothing.
>>>>>>>>>
>>>>>>>>> So what did you change HERE that you think you are the author now?
>>>>>>>>
>>>>>>>> Changes in v6:
>>>>>>>> (Patch 1/3)
>>>>>>>> - Fix description; "Radxa CM5" is the correct name
>>>>>>>
>>>>>>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
>>>>>>> concise and precise answers/comments.
>>>>>>
>>>>>> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
>>>>>>
>>>>>> | By the way, at some point I switched from "continuing your work" to
>>>>>> | "recreating a new one based on my current work." The results of my
>>>>>> | current work(*3) have changed significantly.
>>>>>
>>>>> So next time I will take your patch, your code, say "I recreated it" and
>>>>> submit under my authorship and for you it is fine?
>>>>
>>>> Regarding CM5 patches, I'm fine.
>>>>
>>>>> Please take Joseph's patch instead. Read submitting patches doc to
>>>>> understand which one more tag has to be added when sending somoene
>>>>> else's work.
>>>>>
>>>>> In the future, I sincerely suggest avoiding re-creating people's work
>>>>> but building on top, because you just duplicate the effort.
>>>>
>>>> I understand that you don't understand how I made efforts to build my 
>>>> work on top of Joseph's patches.
>>>
>>> Maybe a solution for this huge mess could be that Naoki submits
>>> unmodified patches from Joseph first, using the standard procedure
>>> for that, and then the additional patch(es) that improve Joseph's
>>> work?  All that in the same series.
>>
>> There is also Co-developed-by as an option.
> 
> Ah, that's what the above-described option #1 involves, but it also 
> raises some possible concerns, described in one of my responses. [1]

There are no concerns to be raised. Please read DCO. The original author
GAVE certified what is necessary, thus any person taking this work
already can you that certification. You raised some uncertainty "I'm not
sure how fair is it for someone to become responsible" which is just not
right here. It is completely fair and completely correct from DCO point
of view, because the certification was already provided. Also from
certification point, there is no "weaker" form. Either you certify or not.

Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 14/11/2025 11:30, Krzysztof Kozlowski wrote:
> On 14/11/2025 11:12, Dragan Simic wrote:
>> Hello Heiko,
>>
>> On Friday, November 14, 2025 11:08 CET, Heiko Stübner <heiko@sntech.de> wrote:
>>> Am Freitag, 14. November 2025, 09:32:29 Mitteleuropäische Normalzeit schrieb Dragan Simic:
>>>> On Friday, November 14, 2025 09:24 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>> On 11/14/25 16:51, Krzysztof Kozlowski wrote:
>>>>>> On 14/11/2025 08:47, FUKAUMI Naoki wrote:
>>>>>>> On 11/14/25 16:42, Krzysztof Kozlowski wrote:
>>>>>>>> On 14/11/2025 08:37, FUKAUMI Naoki wrote:
>>>>>>>>> Hi Krzysztof,
>>>>>>>>>
>>>>>>>>> On 11/14/25 16:12, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 05/11/2025 08:08, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 05/11/2025 07:57, FUKAUMI Naoki wrote:
>>>>>>>>>>>> On 11/5/25 15:43, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>> On 05/11/2025 06:13, FUKAUMI Naoki wrote:
>>>>>>>>>>>>>> Add device tree binding documentation for the Radxa CM5 IO Board.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Link: https://dl.radxa.com/cm5/radxa_cm5_product_brief.pdf
>>>>>>>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>>>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wrong DCO chain.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>      Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
>>>>>>>>>>>>>
>>>>>>>>>>>>> NAK, you just stolen ownership of an already posted patch.
>>>>>>>>>>>>
>>>>>>>>>>>> Read "Changes in v6" and patches; my patches are not the same as v5.
>>>>>>>>>>>> Your reply is totally inappropriate.
>>>>>>>>>>>
>>>>>>>>>>> Inappropriate is taking authorship of someone's patch, because we all
>>>>>>>>>>> expect to preserve the original authorship. That's not only basic
>>>>>>>>>>> decency but actually a standard.
>>>>>>>>>>>
>>>>>>>>>>> Additionally, read Joseph's reply that he wants to continue the work:
>>>>>>>>>>> https://lore.kernel.org/all/CAMWSM7iHtAxewW4JkRqRsifVnccqeFviaCgeOyprKDr92FOurg@mail.gmail.com/
>>>>>>>>>>>
>>>>>>>>>>> You clearly do not understand how to continue with someone's work.
>>>>>>>>>>>
>>>>>>>>>>> It is still a NAK.
>>>>>>>>>>
>>>>>>>>>> And I still wait for justification why you took authorship of this
>>>>>>>>>> patch, because to my eye you changed here nothing.
>>>>>>>>>>
>>>>>>>>>> So what did you change HERE that you think you are the author now?
>>>>>>>>>
>>>>>>>>> Changes in v6:
>>>>>>>>> (Patch 1/3)
>>>>>>>>> - Fix description; "Radxa CM5" is the correct name
>>>>>>>>
>>>>>>>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
>>>>>>>> concise and precise answers/comments.
>>>>>>>
>>>>>>> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
>>>>>>>
>>>>>>> | By the way, at some point I switched from "continuing your work" to
>>>>>>> | "recreating a new one based on my current work." The results of my
>>>>>>> | current work(*3) have changed significantly.
>>>>>>
>>>>>> So next time I will take your patch, your code, say "I recreated it" and
>>>>>> submit under my authorship and for you it is fine?
>>>>>
>>>>> Regarding CM5 patches, I'm fine.
>>>>>
>>>>>> Please take Joseph's patch instead. Read submitting patches doc to
>>>>>> understand which one more tag has to be added when sending somoene
>>>>>> else's work.
>>>>>>
>>>>>> In the future, I sincerely suggest avoiding re-creating people's work
>>>>>> but building on top, because you just duplicate the effort.
>>>>>
>>>>> I understand that you don't understand how I made efforts to build my 
>>>>> work on top of Joseph's patches.
>>>>
>>>> Maybe a solution for this huge mess could be that Naoki submits
>>>> unmodified patches from Joseph first, using the standard procedure
>>>> for that, and then the additional patch(es) that improve Joseph's
>>>> work?  All that in the same series.
>>>
>>> There is also Co-developed-by as an option.
>>
>> Ah, that's what the above-described option #1 involves, but it also 
>> raises some possible concerns, described in one of my responses. [1]
> 
> There are no concerns to be raised. Please read DCO. The original author
> GAVE certified what is necessary, thus any person taking this work
> already can you that certification. You raised some uncertainty "I'm not

Huh, that's barely English... ok, one more try:

There are no concerns to be raised. Please read DCO. The original author
GAVE certification what is necessary, thus any person taking this work
already can use that certification. You raised some uncertainty "I'm not
sure how fair is it for someone to become responsible" which is just not
right here. It is completely fair and completely correct from DCO point
of view, because the certification was already provided. Also from
certification point, there is no "weaker" form. Either you certify or not.

> sure how fair is it for someone to become responsible" which is just not
> right here. It is completely fair and completely correct from DCO point
> of view, because the certification was already provided. Also from
> certification point, there is no "weaker" form. Either you certify or not.




Best regards,
Krzysztof

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

On Friday, November 14, 2025 11:30 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 14/11/2025 11:12, Dragan Simic wrote:
> > On Friday, November 14, 2025 11:08 CET, Heiko Stübner <heiko@sntech.de> wrote:
> >> There is also Co-developed-by as an option.
> > 
> > Ah, that's what the above-described option #1 involves, but it also 
> > raises some possible concerns, described in one of my responses. [1]
> 
> There are no concerns to be raised. Please read DCO. The original author
> GAVE certified what is necessary, thus any person taking this work
> already can you that certification. You raised some uncertainty "I'm not
> sure how fair is it for someone to become responsible" which is just not
> right here. It is completely fair and completely correct from DCO point
> of view, because the certification was already provided. Also from
> certification point, there is no "weaker" form. Either you certify or not.

I see, you're following the documentation strictly and rigidly.
In that case, I think Naoki now knows what's to be done when
submitting these patches again.

Re: [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 14/11/2025 09:24, FUKAUMI Naoki wrote:
>>>>>>
>>>>>> And I still wait for justification why you took authorship of this
>>>>>> patch, because to my eye you changed here nothing.
>>>>>>
>>>>>> So what did you change HERE that you think you are the author now?
>>>>>
>>>>> Changes in v6:
>>>>> (Patch 1/3)
>>>>> - Fix description; "Radxa CM5" is the correct name
>>>>
>>>> HERE, in this patch. Don't paste me hundreds of unrelated code. Write
>>>> concise and precise answers/comments.
>>>
>>> https://lore.kernel.org/linux-rockchip/AE0735A6C797CCFF+10496d73-7c0a-4884-9561-24721305a24f@radxa.com/
>>>
>>> | By the way, at some point I switched from "continuing your work" to
>>> | "recreating a new one based on my current work." The results of my
>>> | current work(*3) have changed significantly.
>>
>> So next time I will take your patch, your code, say "I recreated it" and
>> submit under my authorship and for you it is fine?
> 
> Regarding CM5 patches, I'm fine.
> 
>> Please take Joseph's patch instead. Read submitting patches doc to
>> understand which one more tag has to be added when sending somoene
>> else's work.
>>
>> In the future, I sincerely suggest avoiding re-creating people's work
>> but building on top, because you just duplicate the effort.
> 
> I understand that you don't understand how I made efforts to build my 
> work on top of Joseph's patches.

This patch, I speak about this patch.

Not patches.

Best regards,
Krzysztof

[PATCH v6 2/3] arm64: dts: rockchip: Add Radxa CM5

[FUKAUMI Naoki]

The Radxa CM5 is a high performance embedded SoM based on the Rockchip
RK3588S2 SoC.

Specification:
- Quad-core Cortex-A76 and quad-core Cortex-A55 CPU
- Mali-G610 MP4 GPU
- 6TOPS NPU
- Up to 32GB LPDDR4x RAM
- Up to 128GB on-board eMMC
- On-board Gigabit Ethernet PHY
- RK806-1 PMIC

Link: https://dl.radxa.com/cm5/v2210/radxa_cm5_v2210_schematic.pdf
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 .../boot/dts/rockchip/rk3588s-radxa-cm5.dtsi  | 602 ++++++++++++++++++
 1 file changed, 602 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
new file mode 100644
index 0000000000000..f2da73126c1fe
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
@@ -0,0 +1,602 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Radxa Computer (Shenzhen) Co., Ltd.
+ * Copyright (c) 2025 Joseph Kogut <joseph.kogut@gmail.com>
+ */
+
+/*
+ * CM5 schematic
+ * https://dl.radxa.com/cm5/v2210/radxa_cm5_v2210_schematic.pdf
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3588s.dtsi"
+
+/ {
+	compatible = "radxa,cm5", "rockchip,rk3588s";
+
+	aliases {
+		ethernet0 = &gmac1;
+		mmc0 = &sdhci;
+	};
+
+	keys-0 {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-0 {
+			label = "Maskrom";
+			linux,code = <KEY_SETUP>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	leds-0 {
+		compatible = "gpio-leds";
+
+		led-0 {
+			color = <LED_COLOR_ID_BLUE>;
+			default-state = "on";
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+			pinctrl-names = "default";
+			pinctrl-0 = <&gpio4_b4>;
+		};
+	};
+
+	vcc_1v1_nldo_s3: regulator-1v1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v1_nldo_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc_sysin>;
+	};
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big0_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big1_s0>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-id";
+	phy-supply = <&vcc_3v3_s3>;
+	pinctrl-0 = <&gmac1_miim
+		     &gmac1_tx_bus2
+		     &gmac1_rx_bus2
+		     &gmac1_rgmii_clk
+		     &gmac1_rgmii_bus
+		     &gmac1_clkinout>;
+	pinctrl-names = "default";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu_s0>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m2_xfer>;
+	status = "okay";
+
+	vdd_cpu_big0_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big0_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc_sysin>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_cpu_big1_s0: regulator@43 {
+		compatible = "rockchip,rk8603", "rockchip,rk8602";
+		reg = <0x43>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_big1_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <1050000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc_sysin>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	eeprom@50 {
+		compatible = "belling,bl24c16a", "atmel,24c16";
+		reg = <0x50>;
+		pagesize = <16>;
+		read-only;
+		vcc-supply = <&vcc_3v3_s3>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+
+	vdd_npu_s0: regulator@42 {
+		compatible = "rockchip,rk8602";
+		reg = <0x42>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_npu_s0";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <550000>;
+		regulator-max-microvolt = <950000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc_sysin>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-id001c.c916";
+		reg = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac1_rstn>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pd_gpu {
+	domain-supply = <&vdd_gpu_s0>;
+};
+
+&pd_npu {
+	domain-supply = <&vdd_npu_s0>;
+};
+
+&pinctrl {
+	ethernet {
+		gmac1_rstn: gmac1-rstn {
+			rockchip,pins = <3 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		gpio4_b4: gpio4-b4 {
+			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&rknn_core_0 {
+	npu-supply = <&vdd_npu_s0>;
+	sram-supply = <&vdd_npu_s0>;
+	status = "okay";
+};
+
+&rknn_core_1 {
+	npu-supply = <&vdd_npu_s0>;
+	sram-supply = <&vdd_npu_s0>;
+	status = "okay";
+};
+
+&rknn_core_2 {
+	npu-supply = <&vdd_npu_s0>;
+	sram-supply = <&vdd_npu_s0>;
+	status = "okay";
+};
+
+&rknn_mmu_0 {
+	status = "okay";
+};
+
+&rknn_mmu_1 {
+	status = "okay";
+};
+
+&rknn_mmu_2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca_1v8_s0>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	no-sd;
+	no-sdio;
+	non-removable;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vcc_1v8_s3>;
+	status = "okay";
+};
+
+&spi2 {
+	assigned-clocks = <&cru CLK_SPI2>;
+	assigned-clock-rates = <200000000>;
+	num-cs = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+	status = "okay";
+
+	pmic@0 {
+		compatible = "rockchip,rk806";
+		reg = <0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+			    <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+		spi-max-frequency = <1000000>;
+		system-power-controller;
+
+		vcc1-supply = <&vcc_sysin>;
+		vcc2-supply = <&vcc_sysin>;
+		vcc3-supply = <&vcc_sysin>;
+		vcc4-supply = <&vcc_sysin>;
+		vcc5-supply = <&vcc_sysin>;
+		vcc6-supply = <&vcc_sysin>;
+		vcc7-supply = <&vcc_sysin>;
+		vcc8-supply = <&vcc_sysin>;
+		vcc9-supply = <&vcc_sysin>;
+		vcc10-supply = <&vcc_sysin>;
+		vcc11-supply = <&vcc_2v0_pldo_s3>;
+		vcc12-supply = <&vcc_sysin>;
+		vcc13-supply = <&vcc_1v1_nldo_s3>;
+		vcc14-supply = <&vcc_1v1_nldo_s3>;
+		vcca-supply = <&vcc_sysin>;
+
+		rk806_dvs1_null: dvs1-null-pins {
+			pins = "gpio_pwrctrl1";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs2_null: dvs2-null-pins {
+			pins = "gpio_pwrctrl2";
+			function = "pin_fun0";
+		};
+
+		rk806_dvs3_null: dvs3-null-pins {
+			pins = "gpio_pwrctrl3";
+			function = "pin_fun0";
+		};
+
+		regulators {
+			vdd_gpu_s0: dcdc-reg1 {
+				regulator-name = "vdd_gpu_s0";
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+				regulator-enable-ramp-delay = <400>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_lit_s0: dcdc-reg2 {
+				regulator-name = "vdd_cpu_lit_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_logic_s0: dcdc-reg3 {
+				regulator-name = "vdd_logic_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <800000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdd_vdenc_s0: dcdc-reg4 {
+				regulator-name = "vdd_vdenc_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <550000>;
+				regulator-max-microvolt = <950000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_ddr_s0: dcdc-reg5 {
+				regulator-name = "vdd_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <900000>;
+				regulator-ramp-delay = <12500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdd2_ddr_s3: dcdc-reg6 {
+				regulator-name = "vdd2_ddr_s3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_2v0_pldo_s3: dcdc-reg7 {
+				regulator-name = "vcc_2v0_pldo_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <2000000>;
+				regulator-max-microvolt = <2000000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <2000000>;
+				};
+			};
+
+			vcc_3v3_s0: vcc_3v3_s3: dcdc-reg8 {
+				regulator-name = "vcc_3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vddq_ddr_s0: dcdc-reg9 {
+				regulator-name = "vddq_ddr_s0";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8_s3: dcdc-reg10 {
+				regulator-name = "vcc_1v8_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_1v8_s0: pldo-reg1 {
+				regulator-name = "vcc_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcca_1v8_s0: pldo-reg2 {
+				regulator-name = "vcca_1v8_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdda_1v2_s0: pldo-reg3 {
+				regulator-name = "vdda_1v2_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_3v3_s0: pldo-reg4 {
+				regulator-name = "vcca_3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vccio_sd_s0: pldo-reg5 {
+				regulator-name = "vccio_sd_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			pldo-reg6 {
+				regulator-name = "pldo_reg6";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vdd_0v75_s3: nldo-reg1 {
+				regulator-name = "vdd_0v75_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <750000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_ddr_pll_s0: nldo-reg2 {
+				regulator-name = "vdda_ddr_pll_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <850000>;
+				};
+			};
+
+			vdda_0v75_s0: nldo-reg3 {
+				regulator-name = "vdda_0v75_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <750000>;
+				};
+			};
+
+			vdda_0v85_s0: nldo-reg4 {
+				regulator-name = "vdda_0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			hdmi_vdda0v85_s0: nldo-reg5 {
+				regulator-name = "hdmi_vdda0v85_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <837500>;
+				regulator-max-microvolt = <837500>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+	status = "okay";
+};
+
+&vop {
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
-- 
2.43.0

Re: [PATCH v6 2/3] arm64: dts: rockchip: Add Radxa CM5

[Krzysztof Kozlowski]

On 05/11/2025 06:13, FUKAUMI Naoki wrote:
> The Radxa CM5 is a high performance embedded SoM based on the Rockchip
> RK3588S2 SoC.
> 
> Specification:
> - Quad-core Cortex-A76 and quad-core Cortex-A55 CPU
> - Mali-G610 MP4 GPU
> - 6TOPS NPU
> - Up to 32GB LPDDR4x RAM
> - Up to 128GB on-board eMMC
> - On-board Gigabit Ethernet PHY
> - RK806-1 PMIC
> 
> Link: https://dl.radxa.com/cm5/v2210/radxa_cm5_v2210_schematic.pdf
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>


NAK, wrong DCO chain and not attributed true authorship.

Stop taking other people's work. This was already posted.

Best regards,
Krzysztof

[PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

The Radxa CM5 IO Board is an application board for the Radxa CM5.

Specification:
- 1x HDMI TX
- 2x MIPI DSI
- 2x MIPI CSI
- 1x USB 3.0 Type-A port
- 1x USB 3.0 Type-C port (supports DisplayPort Alt mode)
- 2x USB 2.0 Type-A ports
- 1x Gigabit Ethernet (supports PoE with add-on PoE HAT)
- 1x microSD card slot
- 1x Fan header
- 1x M.2 E Key slot
- 1x Headphone jack with microphone input
- 40-pin GPIO header
- RTC and battery holder
- 12V 5525 DC jack

Link: https://dl.radxa.com/cm5/io_board_v2200/radxa_cm5_io_board_v2200_schematic.pdf
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../dts/rockchip/rk3588s-radxa-cm5-io.dts     | 503 ++++++++++++++++++
 2 files changed, 504 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4cd8ef607f55c..61790f41c57ba 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-rock-5c.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
new file mode 100644
index 0000000000000..12fa8ba83212a
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
@@ -0,0 +1,503 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2025 Radxa Computer (Shenzhen) Co., Ltd.
+ * Copyright (c) 2025 Joseph Kogut <joseph.kogut@gmail.com>
+ */
+
+/*
+ * CM5 IO Board schematic
+ * https://dl.radxa.com/cm5/io_board_v2200/radxa_cm5_io_board_v2200_schematic.pdf
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-radxa-cm5.dtsi"
+
+/ {
+	model = "Radxa CM5 IO Board";
+	compatible = "radxa,cm5-io", "radxa,cm5", "rockchip,rk3588s";
+
+	aliases {
+		mmc1 = &sdmmc;
+	};
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	fan: fan {
+		compatible = "pwm-fan";
+		#cooling-cells = <2>;
+		cooling-levels = <0 64 128 192 255>;
+		fan-supply = <&vcc5v0_sys>;
+		pwms = <&pwm11 0 60000 0>;
+	};
+
+	hdmi0-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi0_con_in: endpoint {
+				remote-endpoint = <&hdmi0_out_con>;
+			};
+		};
+	};
+
+	keys-1 {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-1 {
+			label = "Recovery";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	vcc12v_dcin: regulator-12v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc3v3_wf: regulator-3v3 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PD3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_pwr_en>;
+		regulator-name = "vcc3v3_wf";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_sysin: regulator-4v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sysin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <4000000>;
+		regulator-max-microvolt = <4000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_sys: vcc5v0_usb: regulator-5v0-0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb1: regulator-5v0-1 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren_h>;
+		regulator-name = "vcc5v0_usb1";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vbus5v0_typec: regulator-5v0-2 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&typec5v_pwren_h>;
+		regulator-name = "vbus5v0_typec";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	rfkill-bt {
+		compatible = "rfkill-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&host_wake_bt_h>;
+		radio-type = "bluetooth";
+		shutdown-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+	};
+
+	rfkill-wlan {
+		compatible = "rfkill-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_reg_on_h>;
+		radio-type = "wlan";
+		shutdown-gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>;
+	};
+
+	sound {
+		compatible = "audio-graph-card";
+		label = "rk3588-es8316";
+		dais = <&i2s0_8ch_p0>;
+		routing = "MIC2", "Mic Jack",
+			  "Headphones", "HPOL",
+			  "Headphones", "HPOR";
+		widgets = "Microphone", "Mic Jack",
+			  "Headphone", "Headphones";
+	};
+};
+
+&combphy0_ps {
+	status = "okay";
+};
+
+&combphy2_psu {
+	phy-supply = <&vcc5v0_usb1>;
+	status = "okay";
+};
+
+&gmac1 {
+	status = "okay";
+};
+
+&hdmi0 {
+	status = "okay";
+};
+
+&hdmi0_in {
+	hdmi0_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi0>;
+	};
+};
+
+&hdmi0_out {
+	hdmi0_out_con: endpoint {
+		remote-endpoint = <&hdmi0_con_in>;
+	};
+};
+
+&hdmi0_sound {
+	status = "okay";
+};
+
+&hdptxphy0 {
+	status = "okay";
+};
+
+&i2c6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c6m3_xfer>;
+	status = "okay";
+
+	usb-typec@22 {
+		compatible = "fcs,fusb302";
+		reg = <0x22>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PC4 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cc_int0_l>;
+		vbus-supply = <&vbus5v0_typec>;
+
+		connector {
+			compatible = "usb-c-connector";
+			data-role = "dual";
+			label = "USB-C";
+			/* fusb302 supports PD Rev 2.0 Ver 1.2 */
+			pd-revision = /bits/ 8 <0x2 0x0 0x1 0x2>;
+			power-role = "source";
+			source-pdos =
+				<PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					usbc0_hs: endpoint {
+						remote-endpoint = <&usb_host0_xhci_to_usbc0>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					usbc0_ss: endpoint {
+						remote-endpoint = <&usbdp_phy0_ss>;
+					};
+				};
+
+				port@2 {
+					reg = <2>;
+
+					usbc0_sbu: endpoint {
+						remote-endpoint = <&usbdp_phy0_sbu>;
+					};
+				};
+			};
+		};
+	};
+
+	rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		clock-output-names = "rtc_32k_in";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB0 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int_l>;
+		wakeup-source;
+	};
+};
+
+&i2c8 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c8m2_xfer>;
+	status = "okay";
+
+	audio-codec@11 {
+		compatible = "everest,es8316";
+		reg = <0x11>;
+		assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+		assigned-clock-rates = <12288000>;
+		clocks = <&cru I2S0_8CH_MCLKOUT>;
+		clock-names = "mclk";
+		#sound-dai-cells = <0>;
+
+		port {
+			es8316_p0_0: endpoint {
+				remote-endpoint = <&i2s0_8ch_p0_0>;
+			};
+		};
+	};
+};
+
+&i2s0_8ch {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s0_lrck
+		     &i2s0_mclk
+		     &i2s0_sclk
+		     &i2s0_sdi0
+		     &i2s0_sdo0>;
+	status = "okay";
+
+	i2s0_8ch_p0: port {
+		i2s0_8ch_p0_0: endpoint {
+			dai-format = "i2s";
+			mclk-fs = <256>;
+			remote-endpoint = <&es8316_p0_0>;
+		};
+	};
+};
+
+&i2s5_8ch {
+	status = "okay";
+};
+
+&package_thermal {
+	polling-delay = <1000>;
+
+	trips {
+		package_fan0: package-fan0 {
+			hysteresis = <2000>;
+			temperature = <55000>;
+			type = "active";
+		};
+
+		package_fan1: package-fan1 {
+			hysteresis = <2000>;
+			temperature = <65000>;
+			type = "active";
+		};
+	};
+
+	cooling-maps {
+		map0 {
+			cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+			trip = <&package_fan0>;
+		};
+
+		map1 {
+			cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+			trip = <&package_fan1>;
+		};
+	};
+};
+
+&pcie2x1l2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie20x1_2_perstn_m0>;
+	reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_wf>;
+	status = "okay";
+};
+
+&pinctrl {
+	pcie {
+		pcie20x1_2_perstn_m0: pcie20x1-2-perstn-m0 {
+			rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_pwr_en: wifi-pwr-en {
+			rockchip,pins = <1 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	rfkill {
+		bt_reg_on_h: bt-reg-on-h {
+			rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		host_wake_bt_h: host-wake-bt-h {
+			rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	rtc {
+		rtc_int_l: rtc-int-l {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		cc_int0_l: cc-int0-l {
+			rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb_host_pwren_h: usb-host-pwren-h {
+			rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usbc_sbu_dc: usbc-sbu-dc {
+			rockchip,pins = <3 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>,
+					<3 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		typec5v_pwren_h: typec5v-pwren-h {
+			rockchip,pins = <0 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm11 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm11m3_pins>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	no-sdio;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vccio_sd_s0>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	status = "okay";
+};
+
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	phy-supply = <&vcc5v0_usb1>;
+	status = "okay";
+};
+
+&u2phy3 {
+	status = "okay";
+};
+
+&u2phy3_host {
+	phy-supply = <&vcc5v0_usb1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2m0_xfer>;
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_xhci {
+	usb-role-switch;
+	status = "okay";
+
+	port {
+		usb_host0_xhci_to_usbc0: endpoint {
+			remote-endpoint = <&usbc0_hs>;
+		};
+	};
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usb_host2_xhci {
+	status = "okay";
+};
+
+&usbdp_phy0 {
+	mode-switch;
+	orientation-switch;
+	pinctrl-names = "default";
+	pinctrl-0 = <&usbc_sbu_dc>;
+	sbu1-dc-gpios = <&gpio3 RK_PC4 GPIO_ACTIVE_HIGH>;
+	sbu2-dc-gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	port {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		usbdp_phy0_ss: endpoint@0 {
+			reg = <0>;
+			remote-endpoint = <&usbc0_ss>;
+		};
+
+		usbdp_phy0_sbu: endpoint@1 {
+			reg = <1>;
+			remote-endpoint = <&usbc0_sbu>;
+		};
+	};
+};
+
+&vp0 {
+	vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi0_in_vp0>;
+	};
+};
-- 
2.43.0

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Krzysztof Kozlowski]

On 05/11/2025 06:13, FUKAUMI Naoki wrote:
> The Radxa CM5 IO Board is an application board for the Radxa CM5.
> 
> Specification:
> - 1x HDMI TX
> - 2x MIPI DSI
> - 2x MIPI CSI
> - 1x USB 3.0 Type-A port
> - 1x USB 3.0 Type-C port (supports DisplayPort Alt mode)
> - 2x USB 2.0 Type-A ports
> - 1x Gigabit Ethernet (supports PoE with add-on PoE HAT)
> - 1x microSD card slot
> - 1x Fan header
> - 1x M.2 E Key slot
> - 1x Headphone jack with microphone input
> - 40-pin GPIO header
> - RTC and battery holder
> - 12V 5525 DC jack
> 
> Link: https://dl.radxa.com/cm5/io_board_v2200/radxa_cm5_io_board_v2200_schematic.pdf
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>


Wrong here as well - incorrect author. You cannot just take other
people's work like that!

Best regards,
Krzysztof

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Jimmy Hon]

On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>
> The Radxa CM5 IO Board is an application board for the Radxa CM5.
>
> Specification:

> - 1x microSD card slot

[ snip ]

> +
> +&sdmmc {
> +       bus-width = <4>;
> +       cap-mmc-highspeed;
> +       cap-sd-highspeed;
> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> +       disable-wp;
> +       no-sdio;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
> +       sd-uhs-sdr104;
> +       vmmc-supply = <&vcc_3v3_s3>;
> +       vqmmc-supply = <&vccio_sd_s0>;
> +       status = "okay";
> +};

When used as a TF slot, shouldn't there be a "no-mmc" also?
That's how the Rock 5A, 5B, and 5C were defined.

Jimmy

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

Hi Jimmy,

On 11/6/25 03:27, Jimmy Hon wrote:
> On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>
>> The Radxa CM5 IO Board is an application board for the Radxa CM5.
>>
>> Specification:
> 
>> - 1x microSD card slot
> 
> [ snip ]
> 
>> +
>> +&sdmmc {
>> +       bus-width = <4>;
>> +       cap-mmc-highspeed;
>> +       cap-sd-highspeed;
>> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
>> +       disable-wp;
>> +       no-sdio;
>> +       pinctrl-names = "default";
>> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
>> +       sd-uhs-sdr104;
>> +       vmmc-supply = <&vcc_3v3_s3>;
>> +       vqmmc-supply = <&vccio_sd_s0>;
>> +       status = "okay";
>> +};
> 
> When used as a TF slot, shouldn't there be a "no-mmc" also?

We have "eMMC to uSD."
  https://radxa.com/products/accessories/emmc-to-usd

[  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 
52000000Hz, actual 49500000HZ div = 0)
[  202.178477] mmc1: new high speed MMC card at address 0001
[  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
[  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
[  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
[  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)

(I'm not sure why it says "Not work with the SD slot on the board." I 
will check.)

> That's how the Rock 5A, 5B, and 5C were defined.

I have submitted a patch without "no-mmc" before. I intend to send one 
again when I have the chance.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Jimmy
> 

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

On 11/6/25 08:38, FUKAUMI Naoki wrote:
> Hi Jimmy,
> 
> On 11/6/25 03:27, Jimmy Hon wrote:
>> On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>
>>> The Radxa CM5 IO Board is an application board for the Radxa CM5.
>>>
>>> Specification:
>>
>>> - 1x microSD card slot
>>
>> [ snip ]
>>
>>> +
>>> +&sdmmc {
>>> +       bus-width = <4>;
>>> +       cap-mmc-highspeed;
>>> +       cap-sd-highspeed;
>>> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
>>> +       disable-wp;
>>> +       no-sdio;
>>> +       pinctrl-names = "default";
>>> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
>>> +       sd-uhs-sdr104;
>>> +       vmmc-supply = <&vcc_3v3_s3>;
>>> +       vqmmc-supply = <&vccio_sd_s0>;
>>> +       status = "okay";
>>> +};
>>
>> When used as a TF slot, shouldn't there be a "no-mmc" also?
> 
> We have "eMMC to uSD."
>   https://radxa.com/products/accessories/emmc-to-usd
> 
> [  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 
> 52000000Hz, actual 49500000HZ div = 0)
> [  202.178477] mmc1: new high speed MMC card at address 0001
> [  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
> [  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
> [  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
> [  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)
> 
> (I'm not sure why it says "Not work with the SD slot on the board." I 
> will check.)

There is no hardware limitation. "eMMC to uSD" should work with microSD 
card slot on the board.

That notice means "dts need to be changed".

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

>> That's how the Rock 5A, 5B, and 5C were defined.
> 
> I have submitted a patch without "no-mmc" before. I intend to send one 
> again when I have the chance.
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> Jimmy
>>
> 
> 

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

Hello Naoki,

On Thursday, November 06, 2025 04:17 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 11/6/25 08:38, FUKAUMI Naoki wrote:
> > On 11/6/25 03:27, Jimmy Hon wrote:
> >> On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>
> >>> The Radxa CM5 IO Board is an application board for the Radxa CM5.
> >>>
> >>> Specification:
> >>
> >>> - 1x microSD card slot
> >>
> >> [ snip ]
> >>
> >>> +
> >>> +&sdmmc {
> >>> +       bus-width = <4>;
> >>> +       cap-mmc-highspeed;
> >>> +       cap-sd-highspeed;
> >>> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> >>> +       disable-wp;
> >>> +       no-sdio;
> >>> +       pinctrl-names = "default";
> >>> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
> >>> +       sd-uhs-sdr104;
> >>> +       vmmc-supply = <&vcc_3v3_s3>;
> >>> +       vqmmc-supply = <&vccio_sd_s0>;
> >>> +       status = "okay";
> >>> +};
> >>
> >> When used as a TF slot, shouldn't there be a "no-mmc" also?
> > 
> > We have "eMMC to uSD."
> >   https://radxa.com/products/accessories/emmc-to-usd
> > 
> > [  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 
> > 52000000Hz, actual 49500000HZ div = 0)
> > [  202.178477] mmc1: new high speed MMC card at address 0001
> > [  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
> > [  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
> > [  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
> > [  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)
> > 
> > (I'm not sure why it says "Not work with the SD slot on the board." I 
> > will check.)
> 
> There is no hardware limitation. "eMMC to uSD" should work with microSD 
> card slot on the board.
> 
> That notice means "dts need to be changed".

True, it can work when the microSD slot is put into the hybrid
MMC/microSD mode, which I described in my previous response, but
that's pretty much a hardware hack similar to accessing JTAG
through the microSD slot on Rockchip boards, or to reconfiguring
the USB 3.0 port to work as a native SATA port on the Pine64
Quartz64 SBC.

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

Hello Naoki,

On Thursday, November 06, 2025 00:38 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 11/6/25 03:27, Jimmy Hon wrote:
> > On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>
> >> The Radxa CM5 IO Board is an application board for the Radxa CM5.
> >>
> >> Specification:
> > 
> >> - 1x microSD card slot
> > 
> > [ snip ]
> > 
> >> +
> >> +&sdmmc {
> >> +       bus-width = <4>;
> >> +       cap-mmc-highspeed;
> >> +       cap-sd-highspeed;
> >> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> >> +       disable-wp;
> >> +       no-sdio;
> >> +       pinctrl-names = "default";
> >> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
> >> +       sd-uhs-sdr104;
> >> +       vmmc-supply = <&vcc_3v3_s3>;
> >> +       vqmmc-supply = <&vccio_sd_s0>;
> >> +       status = "okay";
> >> +};
> > 
> > When used as a TF slot, shouldn't there be a "no-mmc" also?
> 
> We have "eMMC to uSD."
>   https://radxa.com/products/accessories/emmc-to-usd
> 
> [  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 
> 52000000Hz, actual 49500000HZ div = 0)
> [  202.178477] mmc1: new high speed MMC card at address 0001
> [  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
> [  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
> [  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
> [  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)
> 
> (I'm not sure why it says "Not work with the SD slot on the board." I 
> will check.)

Thanks for bringing this up, I've always wondered how are such
simple eMMC-to-microSD adapters supposed to work, so this was
a good opportunity to research that a bit further.

In a few words, they're not supposed to work in true microSD card
slots, and they seem to rely on USB card readers that support
multiple card interface standards, but not more than a single card
at once, by wiring their single interface lines in parallel to the
different types of card slots that they provide.

To explain it a bit further, an eMMC chip supports different data
bus widths and a backward-compatible MMC card mode, but they have
very little knowledge about the SD specification, despite being
somewhat similar; the exception is the simplified eMMC boot mode.
This is explained further in the JEDEC JESD84-B51 standard, which
is available freely from the JEDEC website after registration.

This is also confirmed by the kernel messages quoted above, which
show that the eMMC chip is detected as an MMC card this way.

With all that in mind, we should specify "no-mmc" here, because
we're describing a microSD slot, instead of describing some hybrid
MMC/microSD slot.  That also explains why the adapter sold by Radxa
is described as not to be used with microSD card slots on SBCs.  I'd
also like to hear is this adapter/eMMC chip combo recognized by the
kernel when "no-mmc" is specified; it should fail.

Actually, not specifying "no-mmc" here may result in some unforeseen
issues with some (or perhaps many?) microSD cards, because the MMC
drivers will treat them as MMC-capable devices and try to initialize
them as such, which may cause all kinds of issues.  In fact, I'm not
really sure that the MMC drivers are actually implemented in a way
that avoids all possible issues with the storage controllers that
are capable of both SD and MMC modes when neither of "no-sd" and
"no-mmc" is specified in their DT nodes.

Furthermore, it seems that specifying "cap-mmc-highspeed" together
with "no-emmc" is actually redundant, which would make sense, but
further research of the MMC drivers is needed.  I've added that to
my ever-growing TODO list. :)

> > That's how the Rock 5A, 5B, and 5C were defined.
> 
> I have submitted a patch without "no-mmc" before. I intend to send one 
> again when I have the chance.

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

Hi Dragan,

On 11/6/25 12:31, Dragan Simic wrote:
> Hello Naoki,
> 
> On Thursday, November 06, 2025 00:38 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>> On 11/6/25 03:27, Jimmy Hon wrote:
>>> On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>
>>>> The Radxa CM5 IO Board is an application board for the Radxa CM5.
>>>>
>>>> Specification:
>>>
>>>> - 1x microSD card slot
>>>
>>> [ snip ]
>>>
>>>> +
>>>> +&sdmmc {
>>>> +       bus-width = <4>;
>>>> +       cap-mmc-highspeed;
>>>> +       cap-sd-highspeed;
>>>> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
>>>> +       disable-wp;
>>>> +       no-sdio;
>>>> +       pinctrl-names = "default";
>>>> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
>>>> +       sd-uhs-sdr104;
>>>> +       vmmc-supply = <&vcc_3v3_s3>;
>>>> +       vqmmc-supply = <&vccio_sd_s0>;
>>>> +       status = "okay";
>>>> +};
>>>
>>> When used as a TF slot, shouldn't there be a "no-mmc" also?
>>
>> We have "eMMC to uSD."
>>    https://radxa.com/products/accessories/emmc-to-usd
>>
>> [  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req
>> 52000000Hz, actual 49500000HZ div = 0)
>> [  202.178477] mmc1: new high speed MMC card at address 0001
>> [  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
>> [  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
>> [  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
>> [  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)
>>
>> (I'm not sure why it says "Not work with the SD slot on the board." I
>> will check.)
> 
> Thanks for bringing this up, I've always wondered how are such
> simple eMMC-to-microSD adapters supposed to work, so this was
> a good opportunity to research that a bit further.
> 
> In a few words, they're not supposed to work in true microSD card
> slots, and they seem to rely on USB card readers that support
> multiple card interface standards, but not more than a single card
> at once, by wiring their single interface lines in parallel to the
> different types of card slots that they provide.
> 
> To explain it a bit further, an eMMC chip supports different data
> bus widths and a backward-compatible MMC card mode, but they have
> very little knowledge about the SD specification, despite being
> somewhat similar; the exception is the simplified eMMC boot mode.
> This is explained further in the JEDEC JESD84-B51 standard, which
> is available freely from the JEDEC website after registration.
> 
> This is also confirmed by the kernel messages quoted above, which
> show that the eMMC chip is detected as an MMC card this way.
> 
> With all that in mind, we should specify "no-mmc" here, because
> we're describing a microSD slot, instead of describing some hybrid
> MMC/microSD slot.  That also explains why the adapter sold by Radxa
> is described as not to be used with microSD card slots on SBCs.  I'd
> also like to hear is this adapter/eMMC chip combo recognized by the
> kernel when "no-mmc" is specified; it should fail.
> 
> Actually, not specifying "no-mmc" here may result in some unforeseen
> issues with some (or perhaps many?) microSD cards, because the MMC
> drivers will treat them as MMC-capable devices and try to initialize
> them as such, which may cause all kinds of issues.  In fact, I'm not
> really sure that the MMC drivers are actually implemented in a way
> that avoids all possible issues with the storage controllers that
> are capable of both SD and MMC modes when neither of "no-sd" and
> "no-mmc" is specified in their DT nodes.

I have no objection to specifying no-mmc (and removing 
cap-mmc-highspeed). We have a USB eMMC/UFS Module Reader, which is much 
faster than an eMMC to uSD reader :)

> Furthermore, it seems that specifying "cap-mmc-highspeed" together
> with "no-emmc" is actually redundant, which would make sense, but
> further research of the MMC drivers is needed.  I've added that to
> my ever-growing TODO list. :)

Good luck with your ever-growing TODO list!

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

>>> That's how the Rock 5A, 5B, and 5C were defined.
>>
>> I have submitted a patch without "no-mmc" before. I intend to send one
>> again when I have the chance.
> 
> 

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Jimmy Hon]

On Wed, Nov 5, 2025 at 9:31 PM Dragan Simic <dsimic@manjaro.org> wrote:

[ snip ]

>
> With all that in mind, we should specify "no-mmc" here, because
> we're describing a microSD slot, instead of describing some hybrid
> MMC/microSD slot.  That also explains why the adapter sold by Radxa
> is described as not to be used with microSD card slots on SBCs.  I'd
> also like to hear is this adapter/eMMC chip combo recognized by the
> kernel when "no-mmc" is specified; it should fail.
>
> Actually, not specifying "no-mmc" here may result in some unforeseen
> issues with some (or perhaps many?) microSD cards, because the MMC
> drivers will treat them as MMC-capable devices and try to initialize
> them as such, which may cause all kinds of issues.  In fact, I'm not
> really sure that the MMC drivers are actually implemented in a way
> that avoids all possible issues with the storage controllers that
> are capable of both SD and MMC modes when neither of "no-sd" and
> "no-mmc" is specified in their DT nodes.

Hybrid MMC and SD slots are pretty normal on USB card readers. So it's
normal for the host controller to figure out what kind of card is in
the slot.
https://uditagarwal.in/understanding-sd-sdio-and-mmc-interface/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ae3e537eab9f560b516b001eb89f0cd568bdced
was the commit that introduced the device tree properties. By the
wording of the commit message, these device tree properties are used
to indicate to the driver if the host controller hardware is capable
of MMC initialization or SD initialization.

Since the host controller in the RK3588 is capable of all the modes,
these properties do not need to be specified.

Since Radxa has the eMMC to uSD adapter, it makes sense Radxa would
want to configure their microSD card slot on their boards to be a
hybrid SD/MMC slot.

Now, the more fun question is if the adapter can handle eMMC HS200
using the 4-bit bus?

Jimmy

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[FUKAUMI Naoki]

Hi Jimmy,

On 11/6/25 13:53, Jimmy Hon wrote:
> On Wed, Nov 5, 2025 at 9:31 PM Dragan Simic <dsimic@manjaro.org> wrote:
> 
> [ snip ]
> 
>>
>> With all that in mind, we should specify "no-mmc" here, because
>> we're describing a microSD slot, instead of describing some hybrid
>> MMC/microSD slot.  That also explains why the adapter sold by Radxa
>> is described as not to be used with microSD card slots on SBCs.  I'd
>> also like to hear is this adapter/eMMC chip combo recognized by the
>> kernel when "no-mmc" is specified; it should fail.
>>
>> Actually, not specifying "no-mmc" here may result in some unforeseen
>> issues with some (or perhaps many?) microSD cards, because the MMC
>> drivers will treat them as MMC-capable devices and try to initialize
>> them as such, which may cause all kinds of issues.  In fact, I'm not
>> really sure that the MMC drivers are actually implemented in a way
>> that avoids all possible issues with the storage controllers that
>> are capable of both SD and MMC modes when neither of "no-sd" and
>> "no-mmc" is specified in their DT nodes.
> 
> Hybrid MMC and SD slots are pretty normal on USB card readers. So it's
> normal for the host controller to figure out what kind of card is in
> the slot.
> https://uditagarwal.in/understanding-sd-sdio-and-mmc-interface/
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ae3e537eab9f560b516b001eb89f0cd568bdced
> was the commit that introduced the device tree properties. By the
> wording of the commit message, these device tree properties are used
> to indicate to the driver if the host controller hardware is capable
> of MMC initialization or SD initialization.
> 
> Since the host controller in the RK3588 is capable of all the modes,
> these properties do not need to be specified.
> 
> Since Radxa has the eMMC to uSD adapter, it makes sense Radxa would
> want to configure their microSD card slot on their boards to be a
> hybrid SD/MMC slot.
> 
> Now, the more fun question is if the adapter can handle eMMC HS200
> using the 4-bit bus?

I added
  mmc-hs200-1_8v;

I got

[  226.099510] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 
400000Hz, actual 400000HZ div = 0)
[  226.546246] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req 
52000000Hz, actual 49500000HZ div = 0)
[  226.546371] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 
200000000Hz, actual 198000000HZ div = 0)
[  226.656853] dwmmc_rockchip fe2c0000.mmc: Successfully tuned phase to 76
[  226.657011] mmc1: error -110 whilst initialising MMC card
[  226.671469] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req 
300000Hz, actual 300000HZ div = 0)
[  226.793733] mmc1: switch to bus width 4 failed
[  226.798915] mmc1: mmc_select_hs200 failed, error -110
[  226.799390] mmc1: error -110 whilst initialising MMC card
[  226.811549] mmc_host mmc1: Bus speed (slot 0) = 200000Hz (slot req 
200000Hz, actual 200000HZ div = 0)
[  226.947518] mmc1: switch to bus width 4 failed
[  226.954978] mmc1: mmc_select_hs200 failed, error -110
[  226.955454] mmc1: error -110 whilst initialising MMC card

I don't know if this is board-dependent.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Jimmy
> 

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Jimmy Hon]

On Wed, Nov 5, 2025 at 11:09 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>
> Hi Jimmy,
>
> On 11/6/25 13:53, Jimmy Hon wrote:
> > On Wed, Nov 5, 2025 at 9:31 PM Dragan Simic <dsimic@manjaro.org> wrote:
> >
> > [ snip ]
> >
> >>
> >> With all that in mind, we should specify "no-mmc" here, because
> >> we're describing a microSD slot, instead of describing some hybrid
> >> MMC/microSD slot.  That also explains why the adapter sold by Radxa
> >> is described as not to be used with microSD card slots on SBCs.  I'd
> >> also like to hear is this adapter/eMMC chip combo recognized by the
> >> kernel when "no-mmc" is specified; it should fail.
> >>
> >> Actually, not specifying "no-mmc" here may result in some unforeseen
> >> issues with some (or perhaps many?) microSD cards, because the MMC
> >> drivers will treat them as MMC-capable devices and try to initialize
> >> them as such, which may cause all kinds of issues.  In fact, I'm not
> >> really sure that the MMC drivers are actually implemented in a way
> >> that avoids all possible issues with the storage controllers that
> >> are capable of both SD and MMC modes when neither of "no-sd" and
> >> "no-mmc" is specified in their DT nodes.
> >
> > Hybrid MMC and SD slots are pretty normal on USB card readers. So it's
> > normal for the host controller to figure out what kind of card is in
> > the slot.
> > https://uditagarwal.in/understanding-sd-sdio-and-mmc-interface/
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ae3e537eab9f560b516b001eb89f0cd568bdced
> > was the commit that introduced the device tree properties. By the
> > wording of the commit message, these device tree properties are used
> > to indicate to the driver if the host controller hardware is capable
> > of MMC initialization or SD initialization.
> >
> > Since the host controller in the RK3588 is capable of all the modes,
> > these properties do not need to be specified.
> >
> > Since Radxa has the eMMC to uSD adapter, it makes sense Radxa would
> > want to configure their microSD card slot on their boards to be a
> > hybrid SD/MMC slot.
> >
> > Now, the more fun question is if the adapter can handle eMMC HS200
> > using the 4-bit bus?
>
> I added
>   mmc-hs200-1_8v;
>
> I got
>
> [  226.099510] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
> 400000Hz, actual 400000HZ div = 0)
> [  226.546246] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req
> 52000000Hz, actual 49500000HZ div = 0)
> [  226.546371] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req
> 200000000Hz, actual 198000000HZ div = 0)
> [  226.656853] dwmmc_rockchip fe2c0000.mmc: Successfully tuned phase to 76
> [  226.657011] mmc1: error -110 whilst initialising MMC card
> [  226.671469] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req
> 300000Hz, actual 300000HZ div = 0)
> [  226.793733] mmc1: switch to bus width 4 failed
> [  226.798915] mmc1: mmc_select_hs200 failed, error -110
> [  226.799390] mmc1: error -110 whilst initialising MMC card
> [  226.811549] mmc_host mmc1: Bus speed (slot 0) = 200000Hz (slot req
> 200000Hz, actual 200000HZ div = 0)
> [  226.947518] mmc1: switch to bus width 4 failed
> [  226.954978] mmc1: mmc_select_hs200 failed, error -110
> [  226.955454] mmc1: error -110 whilst initialising MMC card
>
> I don't know if this is board-dependent.

I was hoping for too much.

In the "RK3588 Datasheet", under the "eMMC Interface", it specifically
lists support for HS400. However, for the "SD/MMC Interface", it only
mentions "SD3.0, MMC ver4.51", so the more performant eMMC modes are
not available on that interface.

Jimmy

>
> Best regards,
>
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
>
> > Jimmy
> >
>
>

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Dragan Simic]

Hello Jimmy,

On Thursday, November 06, 2025 05:53 CET, Jimmy Hon <honyuenkwun@gmail.com> wrote:
> On Wed, Nov 5, 2025 at 9:31 PM Dragan Simic <dsimic@manjaro.org> wrote:
> > With all that in mind, we should specify "no-mmc" here, because
> > we're describing a microSD slot, instead of describing some hybrid
> > MMC/microSD slot.  That also explains why the adapter sold by Radxa
> > is described as not to be used with microSD card slots on SBCs.  I'd
> > also like to hear is this adapter/eMMC chip combo recognized by the
> > kernel when "no-mmc" is specified; it should fail.
> >
> > Actually, not specifying "no-mmc" here may result in some unforeseen
> > issues with some (or perhaps many?) microSD cards, because the MMC
> > drivers will treat them as MMC-capable devices and try to initialize
> > them as such, which may cause all kinds of issues.  In fact, I'm not
> > really sure that the MMC drivers are actually implemented in a way
> > that avoids all possible issues with the storage controllers that
> > are capable of both SD and MMC modes when neither of "no-sd" and
> > "no-mmc" is specified in their DT nodes.
> 
> Hybrid MMC and SD slots are pretty normal on USB card readers. So it's
> normal for the host controller to figure out what kind of card is in
> the slot.
> https://uditagarwal.in/understanding-sd-sdio-and-mmc-interface/
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ae3e537eab9f560b516b001eb89f0cd568bdced
> was the commit that introduced the device tree properties. By the
> wording of the commit message, these device tree properties are used
> to indicate to the driver if the host controller hardware is capable
> of MMC initialization or SD initialization.
> 
> Since the host controller in the RK3588 is capable of all the modes,
> these properties do not need to be specified.
> 
> Since Radxa has the eMMC to uSD adapter, it makes sense Radxa would
> want to configure their microSD card slot on their boards to be a
> hybrid SD/MMC slot.

Thanks for providing further insights!  After thinking a bit more
about it and after remembering that HardKernel also offers a similar
microSD-to-MMC adapter, [1] there should be very few roadblocks that
may actually prevent us from defining physical microSD slots found
on Rockchip boards as hybrid microSD/MMC slots wherever that's
allowed by the slot implementation and tested to work as expected.
Supporting more card standards is always good.

This approach shouldn't be limited to Radxa (or HardKernel) boards
only, because the available microSD-to-MMC adapters aren't designed
specifically to fit some boards only.

The possible roadblocks, as mentioned above, are some unexpected
signal integrity issues that may prevent the MMC mode from working
as expected on some boards, which Jonas pointed out already, [2][3]
and any associated issues in the MMC drivers.

I'll keep checking the code of MMC drivers for the existence of any
associated issues, and I'll possibly turn a few microSD-only slots
into hybrid ones. :)

[1] https://www.hardkernel.com/shop/emmc-module-reader-board-for-os-upgrade/
[2] https://libera.catirclogs.org/linux-rockchip/2025-11-06#38976445;
[3] https://libera.catirclogs.org/linux-rockchip/2025-11-07#38981060;

Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Radxa CM5 IO Board

[Shawn Lin]

在 2025/11/06 星期四 11:31, Dragan Simic 写道:
> Hello Naoki,
> 
> On Thursday, November 06, 2025 00:38 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>> On 11/6/25 03:27, Jimmy Hon wrote:
>>> On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>
>>>> The Radxa CM5 IO Board is an application board for the Radxa CM5.
>>>>
>>>> Specification:
>>>
>>>> - 1x microSD card slot
>>>
>>> [ snip ]
>>>
>>>> +
>>>> +&sdmmc {
>>>> +       bus-width = <4>;
>>>> +       cap-mmc-highspeed;
>>>> +       cap-sd-highspeed;
>>>> +       cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
>>>> +       disable-wp;
>>>> +       no-sdio;
>>>> +       pinctrl-names = "default";
>>>> +       pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd>;
>>>> +       sd-uhs-sdr104;
>>>> +       vmmc-supply = <&vcc_3v3_s3>;
>>>> +       vqmmc-supply = <&vccio_sd_s0>;
>>>> +       status = "okay";
>>>> +};
>>>
>>> When used as a TF slot, shouldn't there be a "no-mmc" also?
>>
>> We have "eMMC to uSD."
>>    https://radxa.com/products/accessories/emmc-to-usd
>>
>> [  202.176757] mmc_host mmc1: Bus speed (slot 0) = 49500000Hz (slot req
>> 52000000Hz, actual 49500000HZ div = 0)
>> [  202.178477] mmc1: new high speed MMC card at address 0001
>> [  202.179534] mmcblk1: mmc1:0001 SLD64G 57.6 GiB
>> [  202.207336] mmcblk1boot0: mmc1:0001 SLD64G 4.00 MiB
>> [  202.210374] mmcblk1boot1: mmc1:0001 SLD64G 4.00 MiB
>> [  202.212967] mmcblk1rpmb: mmc1:0001 SLD64G 4.00 MiB, chardev (511:1)
>>
>> (I'm not sure why it says "Not work with the SD slot on the board." I
>> will check.)
> 
> Thanks for bringing this up, I've always wondered how are such
> simple eMMC-to-microSD adapters supposed to work, so this was
> a good opportunity to research that a bit further.
> 
> In a few words, they're not supposed to work in true microSD card
> slots, and they seem to rely on USB card readers that support
> multiple card interface standards, but not more than a single card
> at once, by wiring their single interface lines in parallel to the
> different types of card slots that they provide.
> 
> To explain it a bit further, an eMMC chip supports different data
> bus widths and a backward-compatible MMC card mode, but they have
> very little knowledge about the SD specification, despite being
> somewhat similar; the exception is the simplified eMMC boot mode.
> This is explained further in the JEDEC JESD84-B51 standard, which
> is available freely from the JEDEC website after registration.
> 
> This is also confirmed by the kernel messages quoted above, which
> show that the eMMC chip is detected as an MMC card this way.
> 
> With all that in mind, we should specify "no-mmc" here, because
> we're describing a microSD slot, instead of describing some hybrid
> MMC/microSD slot.  That also explains why the adapter sold by Radxa
> is described as not to be used with microSD card slots on SBCs.  I'd
> also like to hear is this adapter/eMMC chip combo recognized by the
> kernel when "no-mmc" is specified; it should fail.
> 
> Actually, not specifying "no-mmc" here may result in some unforeseen
> issues with some (or perhaps many?) microSD cards, because the MMC
> drivers will treat them as MMC-capable devices and try to initialize

Just chime in: The reason why we introduced these, is for controllers
not cards. AFAITC, before commit 6ae3e537eab9f5, we had done that way
for a decade, but rarely saw problems in this field.

> them as such, which may cause all kinds of issues.  In fact, I'm not
> really sure that the MMC drivers are actually implemented in a way
> that avoids all possible issues with the storage controllers that
> are capable of both SD and MMC modes when neither of "no-sd" and
> "no-mmc" is specified in their DT nodes.
> 
> Furthermore, it seems that specifying "cap-mmc-highspeed" together
> with "no-emmc" is actually redundant, which would make sense, but
> further research of the MMC drivers is needed.  I've added that to
> my ever-growing TODO list. :)
> 
>>> That's how the Rock 5A, 5B, and 5C were defined.
>>
>> I have submitted a patch without "no-mmc" before. I intend to send one
>> again when I have the chance.
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

I'd like to clarify the situation regarding the v6 patch series I submitted.

The original device tree work for the Radxa CM5 and IO Board was 
authored by Joseph Kogut. I took over the responsibility of getting it 
upstreamed with his agreement.

However, I now understand that I should have preserved the original 
Signed-off-by chain (and DCO) in the v6 series. This was my oversight.

To correct this, I would prefer for Joseph to post the patches himself, 
which will not include my Signed-off-by.

My apologies for the confusion this caused. Thank you for pointing this out.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 11/5/25 14:13, FUKAUMI Naoki wrote:
> This patch series add support for the Radxa CM5 SoM and IO Board.
> 
> Changes in v6:
> (Patch 1/3)
> - Fix description; "Radxa CM5" is the correct name
> (Patch 2/3)
> - Fix #include(s)
> - Include rk3588s.dtsi
> - Move alias for gmac1 from io board dts
> - Add Maskrom key
> - Add pinctrl-* for led-0
> - Add vcc_1v1_nldo_s3 regulator for pmic
> - Move gmac1 (except status) from io board dts
> - Fix phy-supply for gmac1
> - Fix compatible for vdd_cpu_big1_s0 regulator
> - Add eeprom on i2c0
> - Add vdd_npu_s0 regulator for rknn
> - Fix compatible for rgmii_phy1
> - Add pinctrl-* and reset-* for rgmii_phy1
> - Add domain-supply for pd_npu
> - Add rknn_*
> - Add saradc
> - Fix properties in sdhci
> - Move pmic from io board dts
> - Fix vcc*-supply for pmic
> - Add regulators in pmic
> - Add tsadc
> - Move vop(_mmu) from io board dts
> - Trivial changes (labels, names, etc)
> (Patch 3/3)
> - Fix #include(s)
> - Remove #include "rk3588s.dtsi"
> - Fix model
> - Add fan
> - Add Recovery key
> - Add pinctrl-* for vcc3v3_wf
> - Add vcc_sysin regulator
> - Add pinctrl-* for vbus5v0_typec
> - Add rfkill-bt and rfkill-wlan for M.2 module
> - Add sound for es8316
> - Add phy-supply for combphy2_psu
> - Fix power-role to "source" for fusb302
> - Add rtc for hym8536
> - Add audio-codec on i2c8 for es8316
> - Add i2s0_8ch for es8316
> - Add package_thermal for fan
> - Add pinctrl-* for pcie2x1l2
> - Add pwm11 for fan
> - Fix properties in sdmmmc
> - Add phy-supply for u2phy2_host and u2phy3_host
> - Remove usb_host0_ohci
> - Add pinctrl-* for usbdp_phy0
> - Trivial changes (labels, names, etc)
> 
> Changes in v5:
> (Patch 2/3, per Jimmy)
> - Alias eMMC to mmc0
> - Remove unused sdio alias
> - Move gmac, hdmi0 nodes to carrier board dts
> (Patch 3/3, per Jimmy)
> - Enable hdmi0_sound and i2s5_8ch
> - Remove redundant enablement of sdhci
> - Enable usb_host2_xhci
> 
> - Tested HDMI audio
> 
> Changes in v4:
> - Fixed XHCI initialization bug by changing try-power-role from source
>    to sink
> 
> Changes in v3:
> - Addressed YAML syntax error in dt binding (per Rob)
> - Fixed whitespace issue in dts reported by checkpatch.pl
> - Split base SoM and carrier board into separate patches
> - Added further details about the SoM and carrier to the commit
>    messages
> 
> Changes in v2:
> - Added copyright header and data sheet links
> - Removed non-existent property
> - Sorted alphabetically
> - Removed errant whitespace
> - Moved status to the end of each node
> - Removed pinctrl-names property from leds (indicated by CHECK_DTBS)
> - Removed delays from gmac with internal delay
> 
> Link: https://lore.kernel.org/r/20250617-rk3588s-cm5-io-dts-upstream-v5-0-8d96854a5bbd@gmail.com
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> ---
> I have communicated with Joseph privately and taken ownership of
> moving this forward, with his blessing. All bugs belong to me.
> ---
> FUKAUMI Naoki (3):
>    dt-bindings: arm: rockchip: Add Radxa CM5 IO Board
>    arm64: dts: rockchip: Add Radxa CM5
>    arm64: dts: rockchip: Add Radxa CM5 IO Board
> 
>   .../devicetree/bindings/arm/rockchip.yaml     |   7 +
>   arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>   .../dts/rockchip/rk3588s-radxa-cm5-io.dts     | 503 +++++++++++++++
>   .../boot/dts/rockchip/rk3588s-radxa-cm5.dtsi  | 602 ++++++++++++++++++
>   4 files changed, 1113 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts
>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Joseph Kogut]

Hello all,

On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>
> I'd like to clarify the situation regarding the v6 patch series I submitted.
>
> The original device tree work for the Radxa CM5 and IO Board was
> authored by Joseph Kogut. I took over the responsibility of getting it
> upstreamed with his agreement.

I'll confirm this. I've been in communication with Naoki. They made a
large number of revisions to my original patch series, which I think
have technical merit. I suggested they submit the patches themselves,
and gave them explicit permission to add my Signed-off-by and CC me.

I assume this was the correct way for them to continue the work I
started, but if not, please let us know the best way to proceed.

Best,
Joseph

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

Hi all,

On 11/6/25 02:48, Joseph Kogut wrote:
> Hello all,
> 
> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>
>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>
>> The original device tree work for the Radxa CM5 and IO Board was
>> authored by Joseph Kogut. I took over the responsibility of getting it
>> upstreamed with his agreement.
> 
> I'll confirm this. I've been in communication with Naoki. They made a
> large number of revisions to my original patch series, which I think
> have technical merit. I suggested they submit the patches themselves,
> and gave them explicit permission to add my Signed-off-by and CC me.
> 
> I assume this was the correct way for them to continue the work I
> started, but if not, please let us know the best way to proceed.

Can anyone help us?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Best,
> Joseph
> 

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Dragan Simic]

Hello all,

On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 11/6/25 02:48, Joseph Kogut wrote:
> > On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >> I'd like to clarify the situation regarding the v6 patch series I submitted.
> >>
> >> The original device tree work for the Radxa CM5 and IO Board was
> >> authored by Joseph Kogut. I took over the responsibility of getting it
> >> upstreamed with his agreement.
> > 
> > I'll confirm this. I've been in communication with Naoki. They made a
> > large number of revisions to my original patch series, which I think
> > have technical merit. I suggested they submit the patches themselves,
> > and gave them explicit permission to add my Signed-off-by and CC me.
> > 
> > I assume this was the correct way for them to continue the work I
> > started, but if not, please let us know the best way to proceed.
> 
> Can anyone help us?

I'm not exactly sure how to resolve the current situation, but for
Signed-off-by tags to be present, in this case you'd need to have
Co-developed-by tags as well, because the final patch versions,
which would be submitted by Naoki, would differ significantly from
the versions that Joseph actively worked on, if I understood
everything correctly.  Though, for Joseph's Signed-off-by tags to
be included there, he would also need to participate actively in
the development of the final patch versions.

Another option, technically a bit simpler, would be to include just
Originally-by tags for Joseph, which would indicate that Joseph gave
up on the development of the patches and handed them over to Naoki
for future development and submission to the mailing lists. Though,
that would require Joseph to publicly state exactly that.

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

Hi Dragan, Joseph,

On 11/11/25 23:33, Dragan Simic wrote:
> Hello all,
> 
> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>> On 11/6/25 02:48, Joseph Kogut wrote:
>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>
>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>> upstreamed with his agreement.
>>>
>>> I'll confirm this. I've been in communication with Naoki. They made a
>>> large number of revisions to my original patch series, which I think
>>> have technical merit. I suggested they submit the patches themselves,
>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>
>>> I assume this was the correct way for them to continue the work I
>>> started, but if not, please let us know the best way to proceed.
>>
>> Can anyone help us?
> 
> I'm not exactly sure how to resolve the current situation, but for
> Signed-off-by tags to be present, in this case you'd need to have
> Co-developed-by tags as well, because the final patch versions,
> which would be submitted by Naoki, would differ significantly from
> the versions that Joseph actively worked on, if I understood
> everything correctly.  Though, for Joseph's Signed-off-by tags to
> be included there, he would also need to participate actively in
> the development of the final patch versions.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

If
----
From: Joseph Kogut <joseph.kogut@gmail.com>

<changelog>

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
----
then I can submit my patch series?

Or,

> Another option, technically a bit simpler, would be to include just
> Originally-by tags for Joseph, which would indicate that Joseph gave
> up on the development of the patches and handed them over to Naoki
> for future development and submission to the mailing lists. Though,
> that would require Joseph to publicly state exactly that.

I cannot find any documentation about "Originally-by".
Is this correct?
----
<changelog>

Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
----

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Dragan Simic]

Hello Naoki,

On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 11/11/25 23:33, Dragan Simic wrote:
> > On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >> On 11/6/25 02:48, Joseph Kogut wrote:
> >>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
> >>>>
> >>>> The original device tree work for the Radxa CM5 and IO Board was
> >>>> authored by Joseph Kogut. I took over the responsibility of getting it
> >>>> upstreamed with his agreement.
> >>>
> >>> I'll confirm this. I've been in communication with Naoki. They made a
> >>> large number of revisions to my original patch series, which I think
> >>> have technical merit. I suggested they submit the patches themselves,
> >>> and gave them explicit permission to add my Signed-off-by and CC me.
> >>>
> >>> I assume this was the correct way for them to continue the work I
> >>> started, but if not, please let us know the best way to proceed.
> >>
> >> Can anyone help us?
> > 
> > I'm not exactly sure how to resolve the current situation, but for
> > Signed-off-by tags to be present, in this case you'd need to have
> > Co-developed-by tags as well, because the final patch versions,
> > which would be submitted by Naoki, would differ significantly from
> > the versions that Joseph actively worked on, if I understood
> > everything correctly.  Though, for Joseph's Signed-off-by tags to
> > be included there, he would also need to participate actively in
> > the development of the final patch versions.
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> 
> If
> ----
> From: Joseph Kogut <joseph.kogut@gmail.com>
> 
> <changelog>
> 
> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> ----
> then I can submit my patch series?

Actually, the Co-developed-by tags would be pointing to Joseph
in that case, but as I described it above, this approach basically
cannot be used, because Joseph's original work differs a lot from
what you'd actually submit to the mailing list(s).

> Or,
> 
> > Another option, technically a bit simpler, would be to include just
> > Originally-by tags for Joseph, which would indicate that Joseph gave
> > up on the development of the patches and handed them over to Naoki
> > for future development and submission to the mailing lists. Though,
> > that would require Joseph to publicly state exactly that.
> 
> I cannot find any documentation about "Originally-by".
> Is this correct?
> ----
> <changelog>
> 
> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> ----

That approach is the only I see applicable in this case.  However,
let's hear opinions from other people as well.

By the way, what you called changelogs in the examples above is
usually called patch descriptions.  When they become merged, they
become called commit descriptions or, sometimes, commit messages.
Using the standard lingo usually helps. :)

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

Hi Dragan, Joseph, all

On 11/12/25 09:46, Dragan Simic wrote:
> Hello Naoki,
> 
> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>> On 11/11/25 23:33, Dragan Simic wrote:
>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>
>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>> upstreamed with his agreement.
>>>>>
>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>> large number of revisions to my original patch series, which I think
>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>
>>>>> I assume this was the correct way for them to continue the work I
>>>>> started, but if not, please let us know the best way to proceed.
>>>>
>>>> Can anyone help us?
>>>
>>> I'm not exactly sure how to resolve the current situation, but for
>>> Signed-off-by tags to be present, in this case you'd need to have
>>> Co-developed-by tags as well, because the final patch versions,
>>> which would be submitted by Naoki, would differ significantly from
>>> the versions that Joseph actively worked on, if I understood
>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>> be included there, he would also need to participate actively in
>>> the development of the final patch versions.
>>
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>
>> If
>> ----
>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>
>> <changelog>
>>
>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>> ----
>> then I can submit my patch series?
> 
> Actually, the Co-developed-by tags would be pointing to Joseph
> in that case, but as I described it above, this approach basically
> cannot be used, because Joseph's original work differs a lot from
> what you'd actually submit to the mailing list(s).
> 
>> Or,
>>
>>> Another option, technically a bit simpler, would be to include just
>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>> up on the development of the patches and handed them over to Naoki
>>> for future development and submission to the mailing lists. Though,
>>> that would require Joseph to publicly state exactly that.
>>
>> I cannot find any documentation about "Originally-by".
>> Is this correct?
>> ----
>> <changelog>
>>
>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>> ----
> 
> That approach is the only I see applicable in this case.  However,
> let's hear opinions from other people as well.

Thank you very much for your advice.

So I want to hear Joseph's public statement and the opinions of other 
people.

> By the way, what you called changelogs in the examples above is
> usually called patch descriptions.  When they become merged, they
> become called commit descriptions or, sometimes, commit messages.
> Using the standard lingo usually helps. :)

Ah, it comes from
  https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

Should it be fixed? ;)

Best regards

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Dragan Simic]

On Wednesday, November 12, 2025 02:01 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 11/12/25 09:46, Dragan Simic wrote:
> > By the way, what you called changelogs in the examples above is
> > usually called patch descriptions.  When they become merged, they
> > become called commit descriptions or, sometimes, commit messages.
> > Using the standard lingo usually helps. :)
> 
> Ah, it comes from
>   https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> 
> Should it be fixed? ;)

Ah, I see, thanks.  IMHO, the wording in that document should be
adjusted a bit, but I don't have the time and energy required to
actually do that. :)

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

Hi Dragan, Joseph,

On 11/12/25 09:46, Dragan Simic wrote:
> Hello Naoki,
> 
> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>> On 11/11/25 23:33, Dragan Simic wrote:
>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>
>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>> upstreamed with his agreement.
>>>>>
>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>> large number of revisions to my original patch series, which I think
>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>
>>>>> I assume this was the correct way for them to continue the work I
>>>>> started, but if not, please let us know the best way to proceed.
>>>>
>>>> Can anyone help us?
>>>
>>> I'm not exactly sure how to resolve the current situation, but for
>>> Signed-off-by tags to be present, in this case you'd need to have
>>> Co-developed-by tags as well, because the final patch versions,
>>> which would be submitted by Naoki, would differ significantly from
>>> the versions that Joseph actively worked on, if I understood
>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>> be included there, he would also need to participate actively in
>>> the development of the final patch versions.
>>
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>
>> If
>> ----
>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>
>> <changelog>
>>
>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>> ----
>> then I can submit my patch series?
> 
> Actually, the Co-developed-by tags would be pointing to Joseph
> in that case, but as I described it above, this approach basically
> cannot be used, because Joseph's original work differs a lot from
> what you'd actually submit to the mailing list(s).
> 
>> Or,
>>
>>> Another option, technically a bit simpler, would be to include just
>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>> up on the development of the patches and handed them over to Naoki
>>> for future development and submission to the mailing lists. Though,
>>> that would require Joseph to publicly state exactly that.
>>
>> I cannot find any documentation about "Originally-by".
>> Is this correct?
>> ----
>> <changelog>
>>
>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>> ----
> 
> That approach is the only I see applicable in this case.  However,
> let's hear opinions from other people as well.

I see. I want to do this approach.

Joseph, could you give me a statement to do this?

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> By the way, what you called changelogs in the examples above is
> usually called patch descriptions.  When they become merged, they
> become called commit descriptions or, sometimes, commit messages.
> Using the standard lingo usually helps. :)
> 
> 

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Krzysztof Kozlowski]

On 14/11/2025 06:03, FUKAUMI Naoki wrote:
> Hi Dragan, Joseph,
> 
> On 11/12/25 09:46, Dragan Simic wrote:
>> Hello Naoki,
>>
>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>> On 11/11/25 23:33, Dragan Simic wrote:
>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>>
>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>>> upstreamed with his agreement.
>>>>>>
>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>>> large number of revisions to my original patch series, which I think
>>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>>
>>>>>> I assume this was the correct way for them to continue the work I
>>>>>> started, but if not, please let us know the best way to proceed.
>>>>>
>>>>> Can anyone help us?
>>>>
>>>> I'm not exactly sure how to resolve the current situation, but for
>>>> Signed-off-by tags to be present, in this case you'd need to have
>>>> Co-developed-by tags as well, because the final patch versions,
>>>> which would be submitted by Naoki, would differ significantly from
>>>> the versions that Joseph actively worked on, if I understood
>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>>> be included there, he would also need to participate actively in
>>>> the development of the final patch versions.
>>>
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>>
>>> If
>>> ----
>>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>>
>>> <changelog>
>>>
>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>> ----
>>> then I can submit my patch series?
>>
>> Actually, the Co-developed-by tags would be pointing to Joseph
>> in that case, but as I described it above, this approach basically
>> cannot be used, because Joseph's original work differs a lot from
>> what you'd actually submit to the mailing list(s).
>>
>>> Or,
>>>
>>>> Another option, technically a bit simpler, would be to include just
>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>>> up on the development of the patches and handed them over to Naoki
>>>> for future development and submission to the mailing lists. Though,
>>>> that would require Joseph to publicly state exactly that.
>>>
>>> I cannot find any documentation about "Originally-by".
>>> Is this correct?
>>> ----
>>> <changelog>
>>>
>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>

There is no such tag. Don't invent tags.

>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>> ----
>>
>> That approach is the only I see applicable in this case.  However,
>> let's hear opinions from other people as well.
> 
> I see. I want to do this approach.
> 
> Joseph, could you give me a statement to do this?

Use standard authorship and standard tags, some of which are explained
in Submitting patches.


Best regards,
Krzysztof

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Dragan Simic]

Hello Krzysztof,

On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
> > On 11/12/25 09:46, Dragan Simic wrote:
> >> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>> On 11/11/25 23:33, Dragan Simic wrote:
> >>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>> On 11/6/25 02:48, Joseph Kogut wrote:
> >>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
> >>>>>>>
> >>>>>>> The original device tree work for the Radxa CM5 and IO Board was
> >>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
> >>>>>>> upstreamed with his agreement.
> >>>>>>
> >>>>>> I'll confirm this. I've been in communication with Naoki. They made a
> >>>>>> large number of revisions to my original patch series, which I think
> >>>>>> have technical merit. I suggested they submit the patches themselves,
> >>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
> >>>>>>
> >>>>>> I assume this was the correct way for them to continue the work I
> >>>>>> started, but if not, please let us know the best way to proceed.
> >>>>>
> >>>>> Can anyone help us?
> >>>>
> >>>> I'm not exactly sure how to resolve the current situation, but for
> >>>> Signed-off-by tags to be present, in this case you'd need to have
> >>>> Co-developed-by tags as well, because the final patch versions,
> >>>> which would be submitted by Naoki, would differ significantly from
> >>>> the versions that Joseph actively worked on, if I understood
> >>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
> >>>> be included there, he would also need to participate actively in
> >>>> the development of the final patch versions.
> >>>
> >>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> >>>
> >>> If
> >>> ----
> >>> From: Joseph Kogut <joseph.kogut@gmail.com>
> >>>
> >>> <changelog>
> >>>
> >>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> >>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
> >>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>> ----
> >>> then I can submit my patch series?
> >>
> >> Actually, the Co-developed-by tags would be pointing to Joseph
> >> in that case, but as I described it above, this approach basically
> >> cannot be used, because Joseph's original work differs a lot from
> >> what you'd actually submit to the mailing list(s).
> >>
> >>> Or,
> >>>
> >>>> Another option, technically a bit simpler, would be to include just
> >>>> Originally-by tags for Joseph, which would indicate that Joseph gave
> >>>> up on the development of the patches and handed them over to Naoki
> >>>> for future development and submission to the mailing lists. Though,
> >>>> that would require Joseph to publicly state exactly that.
> >>>
> >>> I cannot find any documentation about "Originally-by".
> >>> Is this correct?
> >>> ----
> >>> <changelog>
> >>>
> >>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
> 
> There is no such tag. Don't invent tags.

True, it doesn't exist officially, but it's been used fairly often.

> >>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>> ----
> >>
> >> That approach is the only I see applicable in this case.  However,
> >> let's hear opinions from other people as well.
> > 
> > I see. I want to do this approach.
> > 
> > Joseph, could you give me a statement to do this?
> 
> Use standard authorship and standard tags, some of which are explained
> in Submitting patches.

Frankly, your suggestion is useless, because it doesn't explain what 
to do in this particular case.

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Krzysztof Kozlowski]

On 14/11/2025 08:17, Dragan Simic wrote:
> Hello Krzysztof,
> 
> On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
>>> On 11/12/25 09:46, Dragan Simic wrote:
>>>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>> On 11/11/25 23:33, Dragan Simic wrote:
>>>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>>>>
>>>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>>>>> upstreamed with his agreement.
>>>>>>>>
>>>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>>>>> large number of revisions to my original patch series, which I think
>>>>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>>>>
>>>>>>>> I assume this was the correct way for them to continue the work I
>>>>>>>> started, but if not, please let us know the best way to proceed.
>>>>>>>
>>>>>>> Can anyone help us?
>>>>>>
>>>>>> I'm not exactly sure how to resolve the current situation, but for
>>>>>> Signed-off-by tags to be present, in this case you'd need to have
>>>>>> Co-developed-by tags as well, because the final patch versions,
>>>>>> which would be submitted by Naoki, would differ significantly from
>>>>>> the versions that Joseph actively worked on, if I understood
>>>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>>>>> be included there, he would also need to participate actively in
>>>>>> the development of the final patch versions.
>>>>>
>>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>>>>
>>>>> If
>>>>> ----
>>>>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>
>>>>> <changelog>
>>>>>
>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>> ----
>>>>> then I can submit my patch series?
>>>>
>>>> Actually, the Co-developed-by tags would be pointing to Joseph
>>>> in that case, but as I described it above, this approach basically
>>>> cannot be used, because Joseph's original work differs a lot from
>>>> what you'd actually submit to the mailing list(s).
>>>>
>>>>> Or,
>>>>>
>>>>>> Another option, technically a bit simpler, would be to include just
>>>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>>>>> up on the development of the patches and handed them over to Naoki
>>>>>> for future development and submission to the mailing lists. Though,
>>>>>> that would require Joseph to publicly state exactly that.
>>>>>
>>>>> I cannot find any documentation about "Originally-by".
>>>>> Is this correct?
>>>>> ----
>>>>> <changelog>
>>>>>
>>>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
>>
>> There is no such tag. Don't invent tags.
> 
> True, it doesn't exist officially, but it's been used fairly often.
> 
>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>> ----
>>>>
>>>> That approach is the only I see applicable in this case.  However,
>>>> let's hear opinions from other people as well.
>>>
>>> I see. I want to do this approach.
>>>
>>> Joseph, could you give me a statement to do this?
>>
>> Use standard authorship and standard tags, some of which are explained
>> in Submitting patches.
> 
> Frankly, your suggestion is useless, because it doesn't explain what 
> to do in this particular case.

Maybe because you did not read the doc...


Best regards,
Krzysztof

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Dragan Simic]

On Friday, November 14, 2025 08:22 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 14/11/2025 08:17, Dragan Simic wrote:
> > On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
> >>> On 11/12/25 09:46, Dragan Simic wrote:
> >>>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>> On 11/11/25 23:33, Dragan Simic wrote:
> >>>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
> >>>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
> >>>>>>>>>
> >>>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
> >>>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
> >>>>>>>>> upstreamed with his agreement.
> >>>>>>>>
> >>>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
> >>>>>>>> large number of revisions to my original patch series, which I think
> >>>>>>>> have technical merit. I suggested they submit the patches themselves,
> >>>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
> >>>>>>>>
> >>>>>>>> I assume this was the correct way for them to continue the work I
> >>>>>>>> started, but if not, please let us know the best way to proceed.
> >>>>>>>
> >>>>>>> Can anyone help us?
> >>>>>>
> >>>>>> I'm not exactly sure how to resolve the current situation, but for
> >>>>>> Signed-off-by tags to be present, in this case you'd need to have
> >>>>>> Co-developed-by tags as well, because the final patch versions,
> >>>>>> which would be submitted by Naoki, would differ significantly from
> >>>>>> the versions that Joseph actively worked on, if I understood
> >>>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
> >>>>>> be included there, he would also need to participate actively in
> >>>>>> the development of the final patch versions.
> >>>>>
> >>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> >>>>>
> >>>>> If
> >>>>> ----
> >>>>> From: Joseph Kogut <joseph.kogut@gmail.com>
> >>>>>
> >>>>> <changelog>
> >>>>>
> >>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> >>>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>> ----
> >>>>> then I can submit my patch series?
> >>>>
> >>>> Actually, the Co-developed-by tags would be pointing to Joseph
> >>>> in that case, but as I described it above, this approach basically
> >>>> cannot be used, because Joseph's original work differs a lot from
> >>>> what you'd actually submit to the mailing list(s).
> >>>>
> >>>>> Or,
> >>>>>
> >>>>>> Another option, technically a bit simpler, would be to include just
> >>>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
> >>>>>> up on the development of the patches and handed them over to Naoki
> >>>>>> for future development and submission to the mailing lists. Though,
> >>>>>> that would require Joseph to publicly state exactly that.
> >>>>>
> >>>>> I cannot find any documentation about "Originally-by".
> >>>>> Is this correct?
> >>>>> ----
> >>>>> <changelog>
> >>>>>
> >>>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
> >>
> >> There is no such tag. Don't invent tags.
> > 
> > True, it doesn't exist officially, but it's been used fairly often.
> > 
> >>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>> ----
> >>>>
> >>>> That approach is the only I see applicable in this case.  However,
> >>>> let's hear opinions from other people as well.
> >>>
> >>> I see. I want to do this approach.
> >>>
> >>> Joseph, could you give me a statement to do this?
> >>
> >> Use standard authorship and standard tags, some of which are explained
> >> in Submitting patches.
> > 
> > Frankly, your suggestion is useless, because it doesn't explain what 
> > to do in this particular case.
> 
> Maybe because you did not read the doc...

I think you already know the answer: I read it multiple times and 
used it as a reference more than once.

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Krzysztof Kozlowski]

On 14/11/2025 08:26, Dragan Simic wrote:
> On Friday, November 14, 2025 08:22 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 14/11/2025 08:17, Dragan Simic wrote:
>>> On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
>>>>> On 11/12/25 09:46, Dragan Simic wrote:
>>>>>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>> On 11/11/25 23:33, Dragan Simic wrote:
>>>>>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>>>>>>
>>>>>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>>>>>>> upstreamed with his agreement.
>>>>>>>>>>
>>>>>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>>>>>>> large number of revisions to my original patch series, which I think
>>>>>>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>>>>>>
>>>>>>>>>> I assume this was the correct way for them to continue the work I
>>>>>>>>>> started, but if not, please let us know the best way to proceed.
>>>>>>>>>
>>>>>>>>> Can anyone help us?
>>>>>>>>
>>>>>>>> I'm not exactly sure how to resolve the current situation, but for
>>>>>>>> Signed-off-by tags to be present, in this case you'd need to have
>>>>>>>> Co-developed-by tags as well, because the final patch versions,
>>>>>>>> which would be submitted by Naoki, would differ significantly from
>>>>>>>> the versions that Joseph actively worked on, if I understood
>>>>>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>>>>>>> be included there, he would also need to participate actively in
>>>>>>>> the development of the final patch versions.
>>>>>>>
>>>>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>>>>>>
>>>>>>> If
>>>>>>> ----
>>>>>>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>>
>>>>>>> <changelog>
>>>>>>>
>>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>> ----
>>>>>>> then I can submit my patch series?
>>>>>>
>>>>>> Actually, the Co-developed-by tags would be pointing to Joseph
>>>>>> in that case, but as I described it above, this approach basically
>>>>>> cannot be used, because Joseph's original work differs a lot from
>>>>>> what you'd actually submit to the mailing list(s).
>>>>>>
>>>>>>> Or,
>>>>>>>
>>>>>>>> Another option, technically a bit simpler, would be to include just
>>>>>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>>>>>>> up on the development of the patches and handed them over to Naoki
>>>>>>>> for future development and submission to the mailing lists. Though,
>>>>>>>> that would require Joseph to publicly state exactly that.
>>>>>>>
>>>>>>> I cannot find any documentation about "Originally-by".
>>>>>>> Is this correct?
>>>>>>> ----
>>>>>>> <changelog>
>>>>>>>
>>>>>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>
>>>> There is no such tag. Don't invent tags.
>>>
>>> True, it doesn't exist officially, but it's been used fairly often.
>>>
>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>>> ----
>>>>>>
>>>>>> That approach is the only I see applicable in this case.  However,
>>>>>> let's hear opinions from other people as well.
>>>>>
>>>>> I see. I want to do this approach.
>>>>>
>>>>> Joseph, could you give me a statement to do this?
>>>>
>>>> Use standard authorship and standard tags, some of which are explained
>>>> in Submitting patches.
>>>
>>> Frankly, your suggestion is useless, because it doesn't explain what 
>>> to do in this particular case.
>>
>> Maybe because you did not read the doc...
> 
> I think you already know the answer: I read it multiple times and 
> used it as a reference more than once.

Then if you read it and saw my objection to inventing tags, you could
guess that only first solution for patches with changes coming from
multiple authors is allowed. Also you would find from that doc, that
patches which were not changed - like in this patchset - must be
attributed to single author followed by SoB. So both cases nicely
explained. Pretty simple once you remove the invented tag option,
because it is really unnecessary.


Best regards,
Krzysztof

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Dragan Simic]

On Friday, November 14, 2025 08:28 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 14/11/2025 08:26, Dragan Simic wrote:
> > On Friday, November 14, 2025 08:22 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 14/11/2025 08:17, Dragan Simic wrote:
> >>> On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
> >>>>> On 11/12/25 09:46, Dragan Simic wrote:
> >>>>>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>>>> On 11/11/25 23:33, Dragan Simic wrote:
> >>>>>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
> >>>>>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
> >>>>>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
> >>>>>>>>>>>
> >>>>>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
> >>>>>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
> >>>>>>>>>>> upstreamed with his agreement.
> >>>>>>>>>>
> >>>>>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
> >>>>>>>>>> large number of revisions to my original patch series, which I think
> >>>>>>>>>> have technical merit. I suggested they submit the patches themselves,
> >>>>>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
> >>>>>>>>>>
> >>>>>>>>>> I assume this was the correct way for them to continue the work I
> >>>>>>>>>> started, but if not, please let us know the best way to proceed.
> >>>>>>>>>
> >>>>>>>>> Can anyone help us?
> >>>>>>>>
> >>>>>>>> I'm not exactly sure how to resolve the current situation, but for
> >>>>>>>> Signed-off-by tags to be present, in this case you'd need to have
> >>>>>>>> Co-developed-by tags as well, because the final patch versions,
> >>>>>>>> which would be submitted by Naoki, would differ significantly from
> >>>>>>>> the versions that Joseph actively worked on, if I understood
> >>>>>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
> >>>>>>>> be included there, he would also need to participate actively in
> >>>>>>>> the development of the final patch versions.
> >>>>>>>
> >>>>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> >>>>>>>
> >>>>>>> If
> >>>>>>> ----
> >>>>>>> From: Joseph Kogut <joseph.kogut@gmail.com>
> >>>>>>>
> >>>>>>> <changelog>
> >>>>>>>
> >>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
> >>>>>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>>>> ----
> >>>>>>> then I can submit my patch series?
> >>>>>>
> >>>>>> Actually, the Co-developed-by tags would be pointing to Joseph
> >>>>>> in that case, but as I described it above, this approach basically
> >>>>>> cannot be used, because Joseph's original work differs a lot from
> >>>>>> what you'd actually submit to the mailing list(s).
> >>>>>>
> >>>>>>> Or,
> >>>>>>>
> >>>>>>>> Another option, technically a bit simpler, would be to include just
> >>>>>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
> >>>>>>>> up on the development of the patches and handed them over to Naoki
> >>>>>>>> for future development and submission to the mailing lists. Though,
> >>>>>>>> that would require Joseph to publicly state exactly that.
> >>>>>>>
> >>>>>>> I cannot find any documentation about "Originally-by".
> >>>>>>> Is this correct?
> >>>>>>> ----
> >>>>>>> <changelog>
> >>>>>>>
> >>>>>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
> >>>>
> >>>> There is no such tag. Don't invent tags.
> >>>
> >>> True, it doesn't exist officially, but it's been used fairly often.
> >>>
> >>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> >>>>>>> ----
> >>>>>>
> >>>>>> That approach is the only I see applicable in this case.  However,
> >>>>>> let's hear opinions from other people as well.
> >>>>>
> >>>>> I see. I want to do this approach.
> >>>>>
> >>>>> Joseph, could you give me a statement to do this?
> >>>>
> >>>> Use standard authorship and standard tags, some of which are explained
> >>>> in Submitting patches.
> >>>
> >>> Frankly, your suggestion is useless, because it doesn't explain what 
> >>> to do in this particular case.
> >>
> >> Maybe because you did not read the doc...
> > 
> > I think you already know the answer: I read it multiple times and 
> > used it as a reference more than once.
> 
> Then if you read it and saw my objection to inventing tags, you could
> guess that only first solution for patches with changes coming from
> multiple authors is allowed. Also you would find from that doc, that
> patches which were not changed - like in this patchset - must be
> attributed to single author followed by SoB. So both cases nicely
> explained. Pretty simple once you remove the invented tag option,
> because it is really unnecessary.

Thanks, I appreciate your detailed response.

Let's have a look at the following excerpt from Documentation/
process/submitting-patches.rst:

 503 Co-developed-by: states that the patch was co-created by multiple developers;
 504 it is used to give attribution to co-authors (in addition to the author
 505 attributed by the From: tag) when several people work on a single patch.  Since
 506 Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
 507 followed by a Signed-off-by: of the associated co-author.  Standard sign-off
 508 procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
 509 chronological history of the patch insofar as possible, regardless of whether
 510 the author is attributed via From: or Co-developed-by:.  Notably, the last
 511 Signed-off-by: must always be that of the developer submitting the patch.

Following that, you're absolutely right that the above-described
first approach is the way to go.  However, providing a Signed-off-by
actually means that, at least formally, the signer becomes legally
responsible for the code in the patch;  I'm not sure how fair is it
for someone to become responsible for something that happened long
time ago, about which they have no longer a clue about, which may
happen in case someone rescues an old, abandoned patch, and changes
or improves it a lot before submitting it to a mailing list?

Of course, what I described is more of a hypothetical case, but the
documentation should be covering such cases as well.

That's where Originally-by, I think, comes as a possible solution;
it's a bit like Acked-by, i.e. it's a "lighter" version of Signed-
off-by, in the sense of effectively not making someone legally
responsible for the code they originally authored but have had
abandoned and which someone else is now submitting, while still
providing the mandatory attribution.

I hope it makes sense.

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Cristian Ciocaltea]

On 11/14/25 9:17 AM, Dragan Simic wrote:
> Hello Krzysztof,
> 
> On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
>>> On 11/12/25 09:46, Dragan Simic wrote:
>>>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>> On 11/11/25 23:33, Dragan Simic wrote:
>>>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>>>>
>>>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>>>>> upstreamed with his agreement.
>>>>>>>>
>>>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>>>>> large number of revisions to my original patch series, which I think
>>>>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>>>>
>>>>>>>> I assume this was the correct way for them to continue the work I
>>>>>>>> started, but if not, please let us know the best way to proceed.
>>>>>>>
>>>>>>> Can anyone help us?
>>>>>>
>>>>>> I'm not exactly sure how to resolve the current situation, but for
>>>>>> Signed-off-by tags to be present, in this case you'd need to have
>>>>>> Co-developed-by tags as well, because the final patch versions,
>>>>>> which would be submitted by Naoki, would differ significantly from
>>>>>> the versions that Joseph actively worked on, if I understood
>>>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>>>>> be included there, he would also need to participate actively in
>>>>>> the development of the final patch versions.
>>>>>
>>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>>>>
>>>>> If
>>>>> ----
>>>>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>
>>>>> <changelog>
>>>>>
>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>> ----
>>>>> then I can submit my patch series?
>>>>
>>>> Actually, the Co-developed-by tags would be pointing to Joseph
>>>> in that case, but as I described it above, this approach basically
>>>> cannot be used, because Joseph's original work differs a lot from
>>>> what you'd actually submit to the mailing list(s).
>>>>
>>>>> Or,
>>>>>
>>>>>> Another option, technically a bit simpler, would be to include just
>>>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>>>>> up on the development of the patches and handed them over to Naoki
>>>>>> for future development and submission to the mailing lists. Though,
>>>>>> that would require Joseph to publicly state exactly that.
>>>>>
>>>>> I cannot find any documentation about "Originally-by".
>>>>> Is this correct?
>>>>> ----
>>>>> <changelog>
>>>>>
>>>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
>>
>> There is no such tag. Don't invent tags.
> 
> True, it doesn't exist officially, but it's been used fairly often.

Hmm, actually this tag seems to be documented, or at least given as an example:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/maintainer-tip.rst?h=v6.18-rc5#n309

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Krzysztof Kozlowski]

On 14/11/2025 09:51, Cristian Ciocaltea wrote:
> On 11/14/25 9:17 AM, Dragan Simic wrote:
>> Hello Krzysztof,
>>
>> On Friday, November 14, 2025 08:10 CET, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> On 14/11/2025 06:03, FUKAUMI Naoki wrote:
>>>> On 11/12/25 09:46, Dragan Simic wrote:
>>>>> On Wednesday, November 12, 2025 00:26 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>> On 11/11/25 23:33, Dragan Simic wrote:
>>>>>>> On Tuesday, November 11, 2025 12:52 CET, FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>>> On 11/6/25 02:48, Joseph Kogut wrote:
>>>>>>>>> On Wed, Nov 5, 2025 at 4:15 AM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>>>>>>>>> I'd like to clarify the situation regarding the v6 patch series I submitted.
>>>>>>>>>>
>>>>>>>>>> The original device tree work for the Radxa CM5 and IO Board was
>>>>>>>>>> authored by Joseph Kogut. I took over the responsibility of getting it
>>>>>>>>>> upstreamed with his agreement.
>>>>>>>>>
>>>>>>>>> I'll confirm this. I've been in communication with Naoki. They made a
>>>>>>>>> large number of revisions to my original patch series, which I think
>>>>>>>>> have technical merit. I suggested they submit the patches themselves,
>>>>>>>>> and gave them explicit permission to add my Signed-off-by and CC me.
>>>>>>>>>
>>>>>>>>> I assume this was the correct way for them to continue the work I
>>>>>>>>> started, but if not, please let us know the best way to proceed.
>>>>>>>>
>>>>>>>> Can anyone help us?
>>>>>>>
>>>>>>> I'm not exactly sure how to resolve the current situation, but for
>>>>>>> Signed-off-by tags to be present, in this case you'd need to have
>>>>>>> Co-developed-by tags as well, because the final patch versions,
>>>>>>> which would be submitted by Naoki, would differ significantly from
>>>>>>> the versions that Joseph actively worked on, if I understood
>>>>>>> everything correctly.  Though, for Joseph's Signed-off-by tags to
>>>>>>> be included there, he would also need to participate actively in
>>>>>>> the development of the final patch versions.
>>>>>>
>>>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>>>>>>
>>>>>> If
>>>>>> ----
>>>>>> From: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>>
>>>>>> <changelog>
>>>>>>
>>>>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>>>> Co-developed-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>>>>> ----
>>>>>> then I can submit my patch series?
>>>>>
>>>>> Actually, the Co-developed-by tags would be pointing to Joseph
>>>>> in that case, but as I described it above, this approach basically
>>>>> cannot be used, because Joseph's original work differs a lot from
>>>>> what you'd actually submit to the mailing list(s).
>>>>>
>>>>>> Or,
>>>>>>
>>>>>>> Another option, technically a bit simpler, would be to include just
>>>>>>> Originally-by tags for Joseph, which would indicate that Joseph gave
>>>>>>> up on the development of the patches and handed them over to Naoki
>>>>>>> for future development and submission to the mailing lists. Though,
>>>>>>> that would require Joseph to publicly state exactly that.
>>>>>>
>>>>>> I cannot find any documentation about "Originally-by".
>>>>>> Is this correct?
>>>>>> ----
>>>>>> <changelog>
>>>>>>
>>>>>> Originally-by: Joseph Kogut <joseph.kogut@gmail.com>
>>>
>>> There is no such tag. Don't invent tags.
>>
>> True, it doesn't exist officially, but it's been used fairly often.
> 
> Hmm, actually this tag seems to be documented, or at least given as an example:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/maintainer-tip.rst?h=v6.18-rc5#n309

Yes, for the tip folks (so three people). If you send to the TIP, their
maintainer profile applies. There are also other specific rules in TIP
which are in contrary to common (as most used) process, e.g. completely
reversed tags (see also Konstantin's explanation about the order which
he implemented in b4).

If you want to use it outside of tip, first this should be added to
common docs and checkpatch. Just like b4 should be changed if you want
to use their order of tags.

Best regards,
Krzysztof

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

Hi Joseph,

On 11/5/25 21:15, FUKAUMI Naoki wrote:
> I'd like to clarify the situation regarding the v6 patch series I 
> submitted.
> 
> The original device tree work for the Radxa CM5 and IO Board was 
> authored by Joseph Kogut. I took over the responsibility of getting it 
> upstreamed with his agreement.
> 
> However, I now understand that I should have preserved the original 
> Signed-off-by chain (and DCO) in the v6 series. This was my oversight.
> 
> To correct this, I would prefer for Joseph to post the patches himself, 
> which will not include my Signed-off-by.

Could you please post the patches?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> My apologies for the confusion this caused. Thank you for pointing this 
> out.
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
> On 11/5/25 14:13, FUKAUMI Naoki wrote:
>> This patch series add support for the Radxa CM5 SoM and IO Board.
>>
>> Changes in v6:
>> (Patch 1/3)
>> - Fix description; "Radxa CM5" is the correct name
>> (Patch 2/3)
>> - Fix #include(s)
>> - Include rk3588s.dtsi
>> - Move alias for gmac1 from io board dts
>> - Add Maskrom key
>> - Add pinctrl-* for led-0
>> - Add vcc_1v1_nldo_s3 regulator for pmic
>> - Move gmac1 (except status) from io board dts
>> - Fix phy-supply for gmac1
>> - Fix compatible for vdd_cpu_big1_s0 regulator
>> - Add eeprom on i2c0
>> - Add vdd_npu_s0 regulator for rknn
>> - Fix compatible for rgmii_phy1
>> - Add pinctrl-* and reset-* for rgmii_phy1
>> - Add domain-supply for pd_npu
>> - Add rknn_*
>> - Add saradc
>> - Fix properties in sdhci
>> - Move pmic from io board dts
>> - Fix vcc*-supply for pmic
>> - Add regulators in pmic
>> - Add tsadc
>> - Move vop(_mmu) from io board dts
>> - Trivial changes (labels, names, etc)
>> (Patch 3/3)
>> - Fix #include(s)
>> - Remove #include "rk3588s.dtsi"
>> - Fix model
>> - Add fan
>> - Add Recovery key
>> - Add pinctrl-* for vcc3v3_wf
>> - Add vcc_sysin regulator
>> - Add pinctrl-* for vbus5v0_typec
>> - Add rfkill-bt and rfkill-wlan for M.2 module
>> - Add sound for es8316
>> - Add phy-supply for combphy2_psu
>> - Fix power-role to "source" for fusb302
>> - Add rtc for hym8536
>> - Add audio-codec on i2c8 for es8316
>> - Add i2s0_8ch for es8316
>> - Add package_thermal for fan
>> - Add pinctrl-* for pcie2x1l2
>> - Add pwm11 for fan
>> - Fix properties in sdmmmc
>> - Add phy-supply for u2phy2_host and u2phy3_host
>> - Remove usb_host0_ohci
>> - Add pinctrl-* for usbdp_phy0
>> - Trivial changes (labels, names, etc)
>>
>> Changes in v5:
>> (Patch 2/3, per Jimmy)
>> - Alias eMMC to mmc0
>> - Remove unused sdio alias
>> - Move gmac, hdmi0 nodes to carrier board dts
>> (Patch 3/3, per Jimmy)
>> - Enable hdmi0_sound and i2s5_8ch
>> - Remove redundant enablement of sdhci
>> - Enable usb_host2_xhci
>>
>> - Tested HDMI audio
>>
>> Changes in v4:
>> - Fixed XHCI initialization bug by changing try-power-role from source
>>    to sink
>>
>> Changes in v3:
>> - Addressed YAML syntax error in dt binding (per Rob)
>> - Fixed whitespace issue in dts reported by checkpatch.pl
>> - Split base SoM and carrier board into separate patches
>> - Added further details about the SoM and carrier to the commit
>>    messages
>>
>> Changes in v2:
>> - Added copyright header and data sheet links
>> - Removed non-existent property
>> - Sorted alphabetically
>> - Removed errant whitespace
>> - Moved status to the end of each node
>> - Removed pinctrl-names property from leds (indicated by CHECK_DTBS)
>> - Removed delays from gmac with internal delay
>>
>> Link: https://lore.kernel.org/r/20250617-rk3588s-cm5-io-dts-upstream- 
>> v5-0-8d96854a5bbd@gmail.com
>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>> ---
>> I have communicated with Joseph privately and taken ownership of
>> moving this forward, with his blessing. All bugs belong to me.
>> ---
>> FUKAUMI Naoki (3):
>>    dt-bindings: arm: rockchip: Add Radxa CM5 IO Board
>>    arm64: dts: rockchip: Add Radxa CM5
>>    arm64: dts: rockchip: Add Radxa CM5 IO Board
>>
>>   .../devicetree/bindings/arm/rockchip.yaml     |   7 +
>>   arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>>   .../dts/rockchip/rk3588s-radxa-cm5-io.dts     | 503 +++++++++++++++
>>   .../boot/dts/rockchip/rk3588s-radxa-cm5.dtsi  | 602 ++++++++++++++++++
>>   4 files changed, 1113 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5- 
>> io.dts
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
> 
> 

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

(Sorry, "To:" was wrong in previous email)

Hi Joseph,

On 11/14/25 17:06, FUKAUMI Naoki wrote:
> Hi Joseph,
> 
> On 11/5/25 21:15, FUKAUMI Naoki wrote:
>> I'd like to clarify the situation regarding the v6 patch series I 
>> submitted.
>>
>> The original device tree work for the Radxa CM5 and IO Board was 
>> authored by Joseph Kogut. I took over the responsibility of getting it 
>> upstreamed with his agreement.
>>
>> However, I now understand that I should have preserved the original 
>> Signed-off-by chain (and DCO) in the v6 series. This was my oversight.
>>
>> To correct this, I would prefer for Joseph to post the patches 
>> himself, which will not include my Signed-off-by.
> 
> Could you please post the patches?

Please ignore the patches I sent as v6. Also, I don't claim my 
copyright. Feel free (not) to use them.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
> 
>> My apologies for the confusion this caused. Thank you for pointing 
>> this out.
>>
>> Best regards,
>>
>> -- 
>> FUKAUMI Naoki
>> Radxa Computer (Shenzhen) Co., Ltd.
>>
>> On 11/5/25 14:13, FUKAUMI Naoki wrote:
>>> This patch series add support for the Radxa CM5 SoM and IO Board.
>>>
>>> Changes in v6:
>>> (Patch 1/3)
>>> - Fix description; "Radxa CM5" is the correct name
>>> (Patch 2/3)
>>> - Fix #include(s)
>>> - Include rk3588s.dtsi
>>> - Move alias for gmac1 from io board dts
>>> - Add Maskrom key
>>> - Add pinctrl-* for led-0
>>> - Add vcc_1v1_nldo_s3 regulator for pmic
>>> - Move gmac1 (except status) from io board dts
>>> - Fix phy-supply for gmac1
>>> - Fix compatible for vdd_cpu_big1_s0 regulator
>>> - Add eeprom on i2c0
>>> - Add vdd_npu_s0 regulator for rknn
>>> - Fix compatible for rgmii_phy1
>>> - Add pinctrl-* and reset-* for rgmii_phy1
>>> - Add domain-supply for pd_npu
>>> - Add rknn_*
>>> - Add saradc
>>> - Fix properties in sdhci
>>> - Move pmic from io board dts
>>> - Fix vcc*-supply for pmic
>>> - Add regulators in pmic
>>> - Add tsadc
>>> - Move vop(_mmu) from io board dts
>>> - Trivial changes (labels, names, etc)
>>> (Patch 3/3)
>>> - Fix #include(s)
>>> - Remove #include "rk3588s.dtsi"
>>> - Fix model
>>> - Add fan
>>> - Add Recovery key
>>> - Add pinctrl-* for vcc3v3_wf
>>> - Add vcc_sysin regulator
>>> - Add pinctrl-* for vbus5v0_typec
>>> - Add rfkill-bt and rfkill-wlan for M.2 module
>>> - Add sound for es8316
>>> - Add phy-supply for combphy2_psu
>>> - Fix power-role to "source" for fusb302
>>> - Add rtc for hym8536
>>> - Add audio-codec on i2c8 for es8316
>>> - Add i2s0_8ch for es8316
>>> - Add package_thermal for fan
>>> - Add pinctrl-* for pcie2x1l2
>>> - Add pwm11 for fan
>>> - Fix properties in sdmmmc
>>> - Add phy-supply for u2phy2_host and u2phy3_host
>>> - Remove usb_host0_ohci
>>> - Add pinctrl-* for usbdp_phy0
>>> - Trivial changes (labels, names, etc)
>>>
>>> Changes in v5:
>>> (Patch 2/3, per Jimmy)
>>> - Alias eMMC to mmc0
>>> - Remove unused sdio alias
>>> - Move gmac, hdmi0 nodes to carrier board dts
>>> (Patch 3/3, per Jimmy)
>>> - Enable hdmi0_sound and i2s5_8ch
>>> - Remove redundant enablement of sdhci
>>> - Enable usb_host2_xhci
>>>
>>> - Tested HDMI audio
>>>
>>> Changes in v4:
>>> - Fixed XHCI initialization bug by changing try-power-role from source
>>>    to sink
>>>
>>> Changes in v3:
>>> - Addressed YAML syntax error in dt binding (per Rob)
>>> - Fixed whitespace issue in dts reported by checkpatch.pl
>>> - Split base SoM and carrier board into separate patches
>>> - Added further details about the SoM and carrier to the commit
>>>    messages
>>>
>>> Changes in v2:
>>> - Added copyright header and data sheet links
>>> - Removed non-existent property
>>> - Sorted alphabetically
>>> - Removed errant whitespace
>>> - Moved status to the end of each node
>>> - Removed pinctrl-names property from leds (indicated by CHECK_DTBS)
>>> - Removed delays from gmac with internal delay
>>>
>>> Link: https://lore.kernel.org/r/20250617-rk3588s-cm5-io-dts-upstream- 
>>> v5-0-8d96854a5bbd@gmail.com
>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
>>> Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
>>> ---
>>> I have communicated with Joseph privately and taken ownership of
>>> moving this forward, with his blessing. All bugs belong to me.
>>> ---
>>> FUKAUMI Naoki (3):
>>>    dt-bindings: arm: rockchip: Add Radxa CM5 IO Board
>>>    arm64: dts: rockchip: Add Radxa CM5
>>>    arm64: dts: rockchip: Add Radxa CM5 IO Board
>>>
>>>   .../devicetree/bindings/arm/rockchip.yaml     |   7 +
>>>   arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>>>   .../dts/rockchip/rk3588s-radxa-cm5-io.dts     | 503 +++++++++++++++
>>>   .../boot/dts/rockchip/rk3588s-radxa-cm5.dtsi  | 602 ++++++++++++++++++
>>>   4 files changed, 1113 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5- 
>>> io.dts
>>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5.dtsi
>>
>>
> 

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[Jimmy Hon]

On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>
> This patch series add support for the Radxa CM5 SoM and IO Board.
>
> Changes in v6:
> (Patch 1/3)
> - Fix description; "Radxa CM5" is the correct name
> (Patch 2/3)
> - Fix #include(s)
> - Include rk3588s.dtsi
> - Move alias for gmac1 from io board dts

I'm curious why the alias was moved to the SoM? If the carrier board
does not enable the gmac1, shouldn't we leave out the alias?
i.e. for the handheld without RJ45 jack [1], it wouldn't want the alias, right?

[1] https://github.com/StonedEdge/Retro-Lite-CM5

Jimmy

Re: [PATCH v6 0/3] Add Radxa CM5 and IO Board

[FUKAUMI Naoki]

Hi Jimmy,

On 11/6/25 03:10, Jimmy Hon wrote:
> On Tue, Nov 4, 2025 at 11:14 PM FUKAUMI Naoki <naoki@radxa.com> wrote:
>>
>> This patch series add support for the Radxa CM5 SoM and IO Board.
>>
>> Changes in v6:
>> (Patch 1/3)
>> - Fix description; "Radxa CM5" is the correct name
>> (Patch 2/3)
>> - Fix #include(s)
>> - Include rk3588s.dtsi
>> - Move alias for gmac1 from io board dts
> 
> I'm curious why the alias was moved to the SoM? If the carrier board
> does not enable the gmac1, shouldn't we leave out the alias?
> i.e. for the handheld without RJ45 jack [1], it wouldn't want the alias, right?

Indeed.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> [1] https://github.com/StonedEdge/Retro-Lite-CM5
> 
> Jimmy
>