[PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[Liangbin Lian]

LinkEase EasePi R1 [1] is a high-performance mini router.

Specification:
- Rockchip RK3568
- 2GB/4GB LPDDR4 RAM
- 16GB on-board eMMC
- 1x M.2 key for 2280 NVMe (PCIe 3.0)
- 1x USB 3.0 Type-A
- 1x USB 2.0 Type-C (for USB flashing)
- 2x 1000 Base-T (native, RTL8211F)
- 2x 2500 Base-T (PCIe, RTL8125B)
- 1x HDMI 2.0 Output
- 12v DC Jack
- 1x Power key connected to PMIC
- 2x LEDs (one static power supplied, one GPIO controlled)

[1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html

Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
---

Changes in v2:
- Change deprecated "rockchip,system-power-controller" to "system-power-controller"
- Link to v1: https://lore.kernel.org/r/20250925055906.83375-1-jjm2473@gmail.com/

Changes in v3:
- Fix typo ('status = "disable"' -> 'status = "disabled"') found by kernel test robot https://lore.kernel.org/all/202509261328.Grjhp029-lkp@intel.com/
- Link to v2: https://lore.kernel.org/r/20250925092037.13582-1-jjm2473@gmail.com/

---

Liangbin Lian (3):
  dt-bindings: vendor-prefixes: Document LinkEase
  dt-bindings: arm: rockchip: Add LinkEase EasePi R1
  arm64: dts: rockchip: add LinkEase EasePi R1

 .../devicetree/bindings/arm/rockchip.yaml     |   5 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3568-easepi-r1.dts    | 692 ++++++++++++++++++
 4 files changed, 700 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts


base-commit: d0ca0df179c4b21e2a6c4a4fb637aa8fa14575cb
-- 
2.51.0

[PATCH v3 1/3] dt-bindings: vendor-prefixes: Document LinkEase

[Liangbin Lian]

LinkEase is a company focusing on the research and development of
network equipment and related software and hardware from Shenzhen.

Add vendor prefix for it.

Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 9ec8947dfcad..db496416b250 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -873,6 +873,8 @@ patternProperties:
     description: Lincoln Technology Solutions
   "^lineartechnology,.*":
     description: Linear Technology
+  "^linkease,.*":
+    description: Shenzhen LinkEase Network Technology Co., Ltd.
   "^linksprite,.*":
     description: LinkSprite Technologies, Inc.
   "^linksys,.*":
-- 
2.51.0

[PATCH v3 2/3] dt-bindings: arm: rockchip: Add LinkEase EasePi R1

[Liangbin Lian]

LinkEase EasePi R1 is a high-performance mini router based on RK3568.

Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 28db6bd6aa5b..ec2271cfb7e1 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -726,6 +726,11 @@ properties:
           - const: lckfb,tspi-rk3566
           - const: rockchip,rk3566
 
+      - description: LinkEase EasePi R1
+        items:
+          - const: linkease,easepi-r1
+          - const: rockchip,rk3568
+
       - description: Luckfox Core3576 Module based boards
         items:
           - enum:
-- 
2.51.0

[PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Liangbin Lian]

LinkEase EasePi R1 [1] is a high-performance mini router.

Specification:
- Rockchip RK3568
- 2GB/4GB LPDDR4 RAM
- 16GB on-board eMMC
- 1x M.2 key for 2280 NVMe (PCIe 3.0)
- 1x USB 3.0 Type-A
- 1x USB 2.0 Type-C (for USB flashing)
- 2x 1000 Base-T (native, RTL8211F)
- 2x 2500 Base-T (PCIe, RTL8125B)
- 1x HDMI 2.0 Output
- 12v DC Jack
- 1x Power key connected to PMIC
- 2x LEDs (one static power supplied, one GPIO controlled)

[1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html

Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3568-easepi-r1.dts    | 692 ++++++++++++++++++
 2 files changed, 693 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 099520962ffb..7646ffd7f309 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -127,6 +127,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-nanopi-r3s.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-bigtreetech-cb2-manta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-bigtreetech-pi2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-easepi-r1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts b/arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
new file mode 100644
index 000000000000..2bc8675efa12
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
@@ -0,0 +1,692 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/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 <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3568.dtsi"
+
+/ {
+	model = "LinkEase EasePi R1";
+	compatible = "linkease,easepi-r1", "rockchip,rk3568";
+
+	aliases {
+		mmc0 = &sdmmc0;
+		mmc1 = &sdhci;
+		mmc2 = &sdmmc2;
+
+		ethernet0 = &gmac0;
+		ethernet1 = &gmac1;
+	};
+
+	chosen: chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+
+		button-recovery {
+			label = "Recovery";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <1750>;
+		};
+	};
+
+	dc_12v: regulator-dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: regulator-vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc3v3_sys: regulator-vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	pcie30_avdd0v9: regulator-pcie30-avdd0v9 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	pcie30_avdd1v8: regulator-pcie30-avdd1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "pcie30_avdd1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	regulator-vdd0v95-25glan {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pwr_25g_pin>;
+		enable-active-high;
+		gpio = <&gpio3 RK_PB1 GPIO_ACTIVE_HIGH>;
+		regulator-name = "vdd0v95_25glan";
+		regulator-min-microvolt = <950000>;
+		regulator-max-microvolt = <950000>;
+		regulator-boot-on;
+		regulator-always-on;
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	vcc3v3_nvme: regulator-vcc3v3-nvme {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_nvme";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&dc_12v>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc3v3_nvme_en>;
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk809 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_LOW>;
+	};
+
+	hdmi-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&status_led_pin>;
+
+		status_led: led-status {
+			gpios = <&gpio2 RK_PD7 GPIO_ACTIVE_HIGH>;
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			label = "green:status";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+};
+
+&gmac0 {
+	phy-mode = "rgmii";
+	clock_in_out = "input";
+
+	assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
+	assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
+	assigned-clock-rates = <0>, <125000000>;
+	phy-handle = <&rgmii_phy0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac0_miim
+		     &gmac0_tx_bus2
+		     &gmac0_rx_bus2
+		     &gmac0_rgmii_clk
+		     &gmac0_rgmii_bus>;
+
+	tx_delay = <0x3c>;
+	rx_delay = <0x2f>;
+
+	status = "okay";
+};
+
+&gmac1 {
+	phy-mode = "rgmii";
+	clock_in_out = "input";
+
+	assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+	assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>;
+	assigned-clock-rates = <0>, <125000000>;
+	phy-handle = <&rgmii_phy1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac1m1_miim
+		     &gmac1m1_tx_bus2
+		     &gmac1m1_rx_bus2
+		     &gmac1m1_rgmii_clk
+		     &gmac1m1_rgmii_bus>;
+
+	tx_delay = <0x4f>;
+	rx_delay = <0x26>;
+
+	status = "okay";
+};
+
+&mdio0 {
+	rgmii_phy0: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-0 = <&eth_phy0_reset_pin>;
+		pinctrl-names = "default";
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&mdio1 {
+	rgmii_phy1: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-0 = <&eth_phy1_reset_pin>;
+		pinctrl-names = "default";
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&combphy0 {
+	status = "okay";
+};
+
+&combphy1 {
+	status = "okay";
+};
+
+&combphy2 {
+	status = "okay";
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+	cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&hdmi {
+	avdd-0v9-supply = <&vdda0v9_image>;
+	avdd-1v8-supply = <&vcca1v8_image>;
+	status = "okay";
+};
+
+&hdmi_in {
+	hdmi_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi>;
+	};
+};
+
+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+
+	vdd_cpu: regulator@1c {
+		compatible = "tcs,tcs4525";
+		reg = <0x1c>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1150000>;
+		regulator-ramp-delay = <2300>;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rk809: pmic@20 {
+		compatible = "rockchip,rk809";
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int>;
+		system-power-controller;
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc5-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+		wakeup-source;
+
+		regulators {
+			vdd_logic: DCDC_REG1 {
+				regulator-name = "vdd_logic";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_gpu: DCDC_REG2 {
+				regulator-name = "vdd_gpu";
+				regulator-always-on;
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-initial-mode = <0x2>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vdd_npu: DCDC_REG4 {
+				regulator-name = "vdd_npu";
+				regulator-initial-mode = <0x2>;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG5 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_image: LDO_REG1 {
+				regulator-name = "vdda0v9_image";
+				regulator-min-microvolt = <950000>;
+				regulator-max-microvolt = <950000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v9: LDO_REG2 {
+				regulator-name = "vdda_0v9";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_pmu: LDO_REG3 {
+				regulator-name = "vdda0v9_pmu";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <900000>;
+				};
+			};
+
+			vccio_acodec: LDO_REG4 {
+				regulator-name = "vccio_acodec";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vccio_sd: LDO_REG5 {
+				regulator-name = "vccio_sd";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_pmu: LDO_REG6 {
+				regulator-name = "vcc3v3_pmu";
+				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>;
+				};
+			};
+
+			vcca_1v8: LDO_REG7 {
+				regulator-name = "vcca_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pmu: LDO_REG8 {
+				regulator-name = "vcca1v8_pmu";
+				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>;
+				};
+			};
+
+			vcca1v8_image: LDO_REG9 {
+				regulator-name = "vcca1v8_image";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v3: SWITCH_REG1 {
+				regulator-name = "vcc_3v3";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_sd: SWITCH_REG2 {
+				regulator-name = "vcc3v3_sd";
+				regulator-always-on;
+				regulator-boot-on;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+
+	};
+};
+
+&i2s0_8ch {
+	status = "okay";
+};
+
+/* ETH3 */
+&pcie2x1 {
+	reset-gpios = <&gpio3 RK_PA4 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&pcie30phy {
+	data-lanes = <1 2>;
+	status = "okay";
+};
+
+/* ETH2 */
+&pcie3x1 {
+	num-lanes = <1>;
+	reset-gpios = <&gpio3 RK_PA3 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+/* M.2 Key for 2280 NVMe */
+&pcie3x2 {
+	num-lanes = <1>;
+	reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+	vpcie3v3-supply = <&vcc3v3_nvme>;
+	status = "okay";
+};
+
+&pinctrl {
+	gmac0 {
+		eth_phy0_reset_pin: eth-phy0-reset-pin {
+			rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+	gmac1 {
+		eth_phy1_reset_pin: eth-phy1-reset-pin {
+			rockchip,pins = <2 RK_PD1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	gpio-leds {
+		status_led_pin: status-led-pin {
+			rockchip,pins =
+				<2 RK_PD7 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int: pmic-int {
+			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	pcie-nic {
+		pwr_25g_pin: pwr-25g-pin {
+			rockchip,pins = <3 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	nvme {
+		vcc3v3_nvme_en: vcc3v3-nvme-en {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+};
+
+&pmu_io_domains {
+	pmuio1-supply = <&vcc3v3_pmu>;
+	pmuio2-supply = <&vcc3v3_pmu>;
+	vccio1-supply = <&vccio_acodec>;
+	vccio3-supply = <&vccio_sd>;
+	vccio4-supply = <&vcc_1v8>;
+	vccio5-supply = <&vcc_3v3>;
+	vccio6-supply = <&vcc_1v8>;
+	vccio7-supply = <&vcc_3v3>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca_1v8>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+	status = "okay";
+};
+
+/* Micro SD card slot is not mounted */
+&sdmmc0 {
+	max-frequency = <150000000>;
+	no-sdio;
+	no-mmc;
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+	vmmc-supply = <&vcc3v3_sd>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "disabled";
+};
+
+/* Wifi module is not mounted */
+&sdmmc2 {
+	max-frequency = <150000000>;
+	bus-width = <4>;
+	disable-wp;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_cmd &sdmmc2m0_clk>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sys>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "disabled";
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>;
+	rockchip,hw-tshut-polarity = <0>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+/* OTG Only USB2.0, Only device mode */
+&usb_host0_xhci {
+	phys = <&usb2phy0_otg>;
+	phy-names = "usb2-phy";
+	extcon = <&usb2phy0>;
+	maximum-speed = "high-speed";
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usb_host1_xhci {
+	status = "okay";
+};
+
+&usb2phy0 {
+	status = "okay";
+};
+
+&usb2phy0_host {
+	phy-supply = <&vcc5v0_sys>;
+	status = "okay";
+};
+
+&usb2phy0_otg {
+	status = "okay";
+};
+
+&vop {
+	assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+	assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
-- 
2.51.0

Re: [PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Mon Sep 29, 2025 at 8:57 AM CEST, Liangbin Lian wrote:
> LinkEase EasePi R1 [1] is a high-performance mini router.
> ...
> [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html
>
> Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
> ---
>
> Changes in v2:
> - Change deprecated "rockchip,system-power-controller" to "system-power-controller"
> - Link to v1: https://lore.kernel.org/r/20250925055906.83375-1-jjm2473@gmail.com/

You received an Acked-by on patch 1 and 2 in v1 of this patch set.
You're supposed to add that to the next/new version(s) or explain why
you choose not to do that (bc f.e. there was a major change, but that
does not seem applicable to those patches).

Cheers,
  Diederik

> Changes in v3:
> - Fix typo ('status = "disable"' -> 'status = "disabled"') found by kernel test robot https://lore.kernel.org/all/202509261328.Grjhp029-lkp@intel.com/
> - Link to v2: https://lore.kernel.org/r/20250925092037.13582-1-jjm2473@gmail.com/
>
> ---
>
> Liangbin Lian (3):
>   dt-bindings: vendor-prefixes: Document LinkEase
>   dt-bindings: arm: rockchip: Add LinkEase EasePi R1
>   arm64: dts: rockchip: add LinkEase EasePi R1
>
>  .../devicetree/bindings/arm/rockchip.yaml     |   5 +
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../boot/dts/rockchip/rk3568-easepi-r1.dts    | 692 ++++++++++++++++++
>  4 files changed, 700 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
>
>
> base-commit: d0ca0df179c4b21e2a6c4a4fb637aa8fa14575cb


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 1/3] dt-bindings: vendor-prefixes: Document LinkEase

[Heiko Stuebner]

Am Montag, 29. September 2025, 08:57:12 Mitteleuropäische Sommerzeit schrieb Liangbin Lian:
> LinkEase is a company focusing on the research and development of
> network equipment and related software and hardware from Shenzhen.
> 
> Add vendor prefix for it.
> 
> Signed-off-by: Liangbin Lian <jjm2473@gmail.com>

In v1 this patch received an

Acked-by: Conor Dooley <conor.dooley@microchip.com>

Re: [PATCH v3 2/3] dt-bindings: arm: rockchip: Add LinkEase EasePi R1

[Heiko Stuebner]

Am Montag, 29. September 2025, 08:57:13 Mitteleuropäische Sommerzeit schrieb Liangbin Lian:
> LinkEase EasePi R1 is a high-performance mini router based on RK3568.
> 
> Signed-off-by: Liangbin Lian <jjm2473@gmail.com>

In v1 this patch received an
Acked-by: Conor Dooley <conor.dooley@microchip.com>

Re: [PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[jjm2473]

I will fix that in v4.

I just forget to add `Acked-by` after `git format-patch`.
I will re-patch my local tree, add `Acked-by` to commit message,
then `git format-patch`.

I have another question. If there are reviewers or co-authors later,
do I need to add it to the commit message and send it again?
Or should the reviewer or co-author add the message and
continue to deliver the patch?

Thanks!
  Liangbin

Diederik de Haas <didi.debian@cknow.org> 于2025年9月29日周一 18:20写道：
>
> On Mon Sep 29, 2025 at 8:57 AM CEST, Liangbin Lian wrote:
> > LinkEase EasePi R1 [1] is a high-performance mini router.
> > ...
> > [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html
> >
> > Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
> > ---
> >
> > Changes in v2:
> > - Change deprecated "rockchip,system-power-controller" to "system-power-controller"
> > - Link to v1: https://lore.kernel.org/r/20250925055906.83375-1-jjm2473@gmail.com/
>
> You received an Acked-by on patch 1 and 2 in v1 of this patch set.
> You're supposed to add that to the next/new version(s) or explain why
> you choose not to do that (bc f.e. there was a major change, but that
> does not seem applicable to those patches).
>
> Cheers,
>   Diederik
>
> > Changes in v3:
> > - Fix typo ('status = "disable"' -> 'status = "disabled"') found by kernel test robot https://lore.kernel.org/all/202509261328.Grjhp029-lkp@intel.com/
> > - Link to v2: https://lore.kernel.org/r/20250925092037.13582-1-jjm2473@gmail.com/
> >
> > ---
> >
> > Liangbin Lian (3):
> >   dt-bindings: vendor-prefixes: Document LinkEase
> >   dt-bindings: arm: rockchip: Add LinkEase EasePi R1
> >   arm64: dts: rockchip: add LinkEase EasePi R1
> >
> >  .../devicetree/bindings/arm/rockchip.yaml     |   5 +
> >  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
> >  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
> >  .../boot/dts/rockchip/rk3568-easepi-r1.dts    | 692 ++++++++++++++++++
> >  4 files changed, 700 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
> >
> >
> > base-commit: d0ca0df179c4b21e2a6c4a4fb637aa8fa14575cb
>

Re: [PATCH v3 2/3] dt-bindings: arm: rockchip: Add LinkEase EasePi R1

[jjm2473]

Heiko Stuebner <heiko@sntech.de> 于2025年9月29日周一 20:28写道：
>
> Am Montag, 29. September 2025, 08:57:13 Mitteleuropäische Sommerzeit schrieb Liangbin Lian:
> > LinkEase EasePi R1 is a high-performance mini router based on RK3568.
> >
> > Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
>
> In v1 this patch received an
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>
>
>

In the next version, I will add 'Acked-by' to the commit message
and then run `git format-patch` to avoid missing it.

Thanks!

Re: [PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

On Mon Sep 29, 2025 at 8:09 PM CEST, jjm2473 wrote:
> I have another question. If there are reviewers or co-authors later,
> do I need to add it to the commit message and send it again?
> Or should the reviewer or co-author add the message and
> continue to deliver the patch?

When you get a Reviewed-by tag, you should add that tag too to a new
version. But there's no need to send a new version to just add those
tags, the tooling used by maintainers picks those up themselves.

If you 'just' get review comments, then you'd usually just
improve the patch and you could reference it in a changelog item (to
indicate you addressed it, ttboyk).
If you think a reviewer helped you 'significantly', you could choose to
add an Helped-by tag, but whether you think someone deserves some
credits that way, is up to you(r judgement).

(Co-)authors are usually known upon first submission. If you later find
out that that list was incorrect/incomplete, then you would add
Co-developed-by + Signed-off-by tags on a new version.

HTH,
  Diederik

> Diederik de Haas <didi.debian@cknow.org> 于2025年9月29日周一 18:20写道：
>>
>> On Mon Sep 29, 2025 at 8:57 AM CEST, Liangbin Lian wrote:
>> > LinkEase EasePi R1 [1] is a high-performance mini router.
>> > ...
>> > [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html
>> >
>> > Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
>> > ---
>> >
>> > Changes in v2:
>> > - Change deprecated "rockchip,system-power-controller" to "system-power-controller"
>> > - Link to v1: https://lore.kernel.org/r/20250925055906.83375-1-jjm2473@gmail.com/
>>
>> You received an Acked-by on patch 1 and 2 in v1 of this patch set.
>> You're supposed to add that to the next/new version(s) or explain why
>> you choose not to do that (bc f.e. there was a major change, but that
>> does not seem applicable to those patches).
>>
>> Cheers,
>>   Diederik
>>
>> > Changes in v3:
>> > - Fix typo ('status = "disable"' -> 'status = "disabled"') found by kernel test robot https://lore.kernel.org/all/202509261328.Grjhp029-lkp@intel.com/
>> > - Link to v2: https://lore.kernel.org/r/20250925092037.13582-1-jjm2473@gmail.com/
>> >
>> > ---
>> >
>> > Liangbin Lian (3):
>> >   dt-bindings: vendor-prefixes: Document LinkEase
>> >   dt-bindings: arm: rockchip: Add LinkEase EasePi R1
>> >   arm64: dts: rockchip: add LinkEase EasePi R1
>> >
>> >  .../devicetree/bindings/arm/rockchip.yaml     |   5 +
>> >  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>> >  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>> >  .../boot/dts/rockchip/rk3568-easepi-r1.dts    | 692 ++++++++++++++++++
>> >  4 files changed, 700 insertions(+)
>> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
>> >
>> >
>> > base-commit: d0ca0df179c4b21e2a6c4a4fb637aa8fa14575cb
>>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[jjm2473]

Thanks for your explanation! I got it.
  Liangbin

Diederik de Haas <didi.debian@cknow.org> 于2025年9月30日周二 19:19写道：
>
> On Mon Sep 29, 2025 at 8:09 PM CEST, jjm2473 wrote:
> > I have another question. If there are reviewers or co-authors later,
> > do I need to add it to the commit message and send it again?
> > Or should the reviewer or co-author add the message and
> > continue to deliver the patch?
>
> When you get a Reviewed-by tag, you should add that tag too to a new
> version. But there's no need to send a new version to just add those
> tags, the tooling used by maintainers picks those up themselves.
>
> If you 'just' get review comments, then you'd usually just
> improve the patch and you could reference it in a changelog item (to
> indicate you addressed it, ttboyk).
> If you think a reviewer helped you 'significantly', you could choose to
> add an Helped-by tag, but whether you think someone deserves some
> credits that way, is up to you(r judgement).
>
> (Co-)authors are usually known upon first submission. If you later find
> out that that list was incorrect/incomplete, then you would add
> Co-developed-by + Signed-off-by tags on a new version.
>
> HTH,
>   Diederik
>
> > Diederik de Haas <didi.debian@cknow.org> 于2025年9月29日周一 18:20写道：
> >>
> >> On Mon Sep 29, 2025 at 8:57 AM CEST, Liangbin Lian wrote:
> >> > LinkEase EasePi R1 [1] is a high-performance mini router.
> >> > ...
> >> > [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html
> >> >
> >> > Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
> >> > ---
> >> >
> >> > Changes in v2:
> >> > - Change deprecated "rockchip,system-power-controller" to "system-power-controller"
> >> > - Link to v1: https://lore.kernel.org/r/20250925055906.83375-1-jjm2473@gmail.com/
> >>
> >> You received an Acked-by on patch 1 and 2 in v1 of this patch set.
> >> You're supposed to add that to the next/new version(s) or explain why
> >> you choose not to do that (bc f.e. there was a major change, but that
> >> does not seem applicable to those patches).
> >>
> >> Cheers,
> >>   Diederik
> >>
> >> > Changes in v3:
> >> > - Fix typo ('status = "disable"' -> 'status = "disabled"') found by kernel test robot https://lore.kernel.org/all/202509261328.Grjhp029-lkp@intel.com/
> >> > - Link to v2: https://lore.kernel.org/r/20250925092037.13582-1-jjm2473@gmail.com/
> >> >
> >> > ---
> >> >
> >> > Liangbin Lian (3):
> >> >   dt-bindings: vendor-prefixes: Document LinkEase
> >> >   dt-bindings: arm: rockchip: Add LinkEase EasePi R1
> >> >   arm64: dts: rockchip: add LinkEase EasePi R1
> >> >
> >> >  .../devicetree/bindings/arm/rockchip.yaml     |   5 +
> >> >  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
> >> >  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
> >> >  .../boot/dts/rockchip/rk3568-easepi-r1.dts    | 692 ++++++++++++++++++
> >> >  4 files changed, 700 insertions(+)
> >> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-easepi-r1.dts
> >> >
> >> >
> >> > base-commit: d0ca0df179c4b21e2a6c4a4fb637aa8fa14575cb
> >>
>

Re: [PATCH v3 2/3] dt-bindings: arm: rockchip: Add LinkEase EasePi R1

[Andrew Lunn]

On Tue, Sep 30, 2025 at 02:20:57AM +0800, jjm2473 wrote:
> Heiko Stuebner <heiko@sntech.de> 于2025年9月29日周一 20:28写道：
> >
> > Am Montag, 29. September 2025, 08:57:13 Mitteleuropäische Sommerzeit schrieb Liangbin Lian:
> > > LinkEase EasePi R1 is a high-performance mini router based on RK3568.
> > >
> > > Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
> >
> > In v1 this patch received an
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> >
> >
> >
> 
> In the next version, I will add 'Acked-by' to the commit message
> and then run `git format-patch` to avoid missing it.

Please consider using b4. It will automagically collect all these
reviewed-by, acked-by tags and all them to the patches for you.

	     Andrew

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Andrew Lunn]

> +&gmac0 {
> +	phy-mode = "rgmii";

Did i really miss this patch series in its earlier version, or did you
ignore me?

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

> +	tx_delay = <0x3c>;
> +	rx_delay = <0x2f>;

Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
us the schematics which clearly show extra long clock lines.

> +/* Micro SD card slot is not mounted */
> +&sdmmc0 {
> +	max-frequency = <150000000>;
> +	no-sdio;
> +	no-mmc;
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	disable-wp;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> +	vmmc-supply = <&vcc3v3_sd>;
> +	vqmmc-supply = <&vccio_sd>;
> +	status = "disabled";
> +};
> +
> +/* Wifi module is not mounted */
> +&sdmmc2 {

What do you mean by "not mounted"?

Often you would say "not populated", to indicate the PCB has all the
tracks in place, but the chip has simply not been soldered in place.

Or is there a connector here, and nothing plugged into the connector?

   Andrew

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[jjm2473]

Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
>
> > +&gmac0 {
> > +     phy-mode = "rgmii";
>
> Did i really miss this patch series in its earlier version, or did you
> ignore me?
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
>
> > +     tx_delay = <0x3c>;
> > +     rx_delay = <0x2f>;
>
> Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> us the schematics which clearly show extra long clock lines.
>
> > +/* Micro SD card slot is not mounted */
> > +&sdmmc0 {
> > +     max-frequency = <150000000>;
> > +     no-sdio;
> > +     no-mmc;
> > +     bus-width = <4>;
> > +     cap-mmc-highspeed;
> > +     cap-sd-highspeed;
> > +     disable-wp;
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> > +     vmmc-supply = <&vcc3v3_sd>;
> > +     vqmmc-supply = <&vccio_sd>;
> > +     status = "disabled";
> > +};
> > +
> > +/* Wifi module is not mounted */
> > +&sdmmc2 {
>
> What do you mean by "not mounted"?
>
> Often you would say "not populated", to indicate the PCB has all the
> tracks in place, but the chip has simply not been soldered in place.
>
> Or is there a connector here, and nothing plugged into the connector?
>
>    Andrew

Andrew:
 Hello! I ran `./scripts/get_maintainer.pl
patches-v4/v4-0003-arm64-dts-rockchip-add-LinkEase-EasePi-R1.patch`
to get maintainer list, and got:
```
Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS,commit_signer:3/41=7%)
Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS)
Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC
support,commit_signer:43/41=100%,authored:4/41=10%,added_lines:12/117=10%,commit_signer:5/6=83%)
Quentin Schulz <quentin.schulz@cherry.de>
(commit_signer:10/41=24%,authored:8/41=20%,added_lines:63/117=54%)
Dragan Simic <dsimic@manjaro.org> (commit_signer:5/41=12%,commit_signer:1/6=17%)
FUKAUMI Naoki <naoki@radxa.com>
(commit_signer:3/41=7%,authored:3/41=7%,removed_lines:1/1=100%)
Peter Robinson <pbrobinson@gmail.com>
(added_lines:9/117=8%,commit_signer:1/6=17%,authored:1/6=17%)
Alexey Charkov <alchark@gmail.com> (added_lines:6/117=5%)
Diederik de Haas <didi.debian@cknow.org>
(commit_signer:4/6=67%,authored:3/6=50%)
Liangbin Lian <jjm2473@gmail.com> (commit_signer:1/6=17%,authored:1/6=17%)
Johan Jonker <jbx6244@gmail.com> (authored:1/6=17%)
devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
linux-kernel@vger.kernel.org (open list)
```
your email address is not listed above.
And I did not receive your comment on the previou versions.

The latest v4 version is here
https://lore.kernel.org/all/20250930055017.67610-1-jjm2473@gmail.com/
.

> What do you mean by "not mounted"?
>
> Often you would say "not populated", to indicate the PCB has all the
> tracks in place, but the chip has simply not been soldered in place.
>
> Or is there a connector here, and nothing plugged into the connector?

The chip/slot has not been soldered. So here should be "not
populated", forgive my poor English.

> Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> us the schematics which clearly show extra long clock lines.

In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237

The tx_delay and rx_delay values were obtained using Rockchip's
automatic scanning tool:
https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf

I will try changing phy-mode = "rgmii-id" later to see if gmac
continues to work properly.

  Liangbin Lian

Re: [PATCH v3 2/3] dt-bindings: arm: rockchip: Add LinkEase EasePi R1

[jjm2473]

Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:43写道：
>
> On Tue, Sep 30, 2025 at 02:20:57AM +0800, jjm2473 wrote:
> > Heiko Stuebner <heiko@sntech.de> 于2025年9月29日周一 20:28写道：
> > >
> > > Am Montag, 29. September 2025, 08:57:13 Mitteleuropäische Sommerzeit schrieb Liangbin Lian:
> > > > LinkEase EasePi R1 is a high-performance mini router based on RK3568.
> > > >
> > > > Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
> > >
> > > In v1 this patch received an
> > > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > >
> > >
> > >
> >
> > In the next version, I will add 'Acked-by' to the commit message
> > and then run `git format-patch` to avoid missing it.
>
> Please consider using b4. It will automagically collect all these
> reviewed-by, acked-by tags and all them to the patches for you.
>
>              Andrew

Thanks for the tip!

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Andrew Lunn]

On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
> >
> > > +&gmac0 {
> > > +     phy-mode = "rgmii";
> >
> > Did i really miss this patch series in its earlier version, or did you
> > ignore me?
> >
> > https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> >
> > > +     tx_delay = <0x3c>;
> > > +     rx_delay = <0x2f>;
> >
> > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > us the schematics which clearly show extra long clock lines.
> >
> > > +/* Micro SD card slot is not mounted */
> > > +&sdmmc0 {
> > > +     max-frequency = <150000000>;
> > > +     no-sdio;
> > > +     no-mmc;
> > > +     bus-width = <4>;
> > > +     cap-mmc-highspeed;
> > > +     cap-sd-highspeed;
> > > +     disable-wp;
> > > +     pinctrl-names = "default";
> > > +     pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> > > +     vmmc-supply = <&vcc3v3_sd>;
> > > +     vqmmc-supply = <&vccio_sd>;
> > > +     status = "disabled";
> > > +};
> > > +
> > > +/* Wifi module is not mounted */
> > > +&sdmmc2 {
> >
> > What do you mean by "not mounted"?
> >
> > Often you would say "not populated", to indicate the PCB has all the
> > tracks in place, but the chip has simply not been soldered in place.
> >
> > Or is there a connector here, and nothing plugged into the connector?
> >
> >    Andrew
> 
> Andrew:
>  Hello! I ran `./scripts/get_maintainer.pl
> patches-v4/v4-0003-arm64-dts-rockchip-add-LinkEase-EasePi-R1.patch`
> to get maintainer list, and got:
> ```
> Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS,commit_signer:3/41=7%)
> Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS)
> Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC
> support,commit_signer:43/41=100%,authored:4/41=10%,added_lines:12/117=10%,commit_signer:5/6=83%)
> Quentin Schulz <quentin.schulz@cherry.de>
> (commit_signer:10/41=24%,authored:8/41=20%,added_lines:63/117=54%)
> Dragan Simic <dsimic@manjaro.org> (commit_signer:5/41=12%,commit_signer:1/6=17%)
> FUKAUMI Naoki <naoki@radxa.com>
> (commit_signer:3/41=7%,authored:3/41=7%,removed_lines:1/1=100%)
> Peter Robinson <pbrobinson@gmail.com>
> (added_lines:9/117=8%,commit_signer:1/6=17%,authored:1/6=17%)
> Alexey Charkov <alchark@gmail.com> (added_lines:6/117=5%)
> Diederik de Haas <didi.debian@cknow.org>
> (commit_signer:4/6=67%,authored:3/6=50%)
> Liangbin Lian <jjm2473@gmail.com> (commit_signer:1/6=17%,authored:1/6=17%)
> Johan Jonker <jbx6244@gmail.com> (authored:1/6=17%)
> devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS)
> linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
> linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
> linux-kernel@vger.kernel.org (open list)
> ```
> your email address is not listed above.

What i eventually found is that you posted v3 separately, and then
threaded v4 to v2, which makes no sense.

Please always start a new thread for each patchset.

> > What do you mean by "not mounted"?
> >
> > Often you would say "not populated", to indicate the PCB has all the
> > tracks in place, but the chip has simply not been soldered in place.
> >
> > Or is there a connector here, and nothing plugged into the connector?
> 
> The chip/slot has not been soldered. So here should be "not
> populated", forgive my poor English.

Thanks for the clarification. I'm not sure it is worth adding these DT
properties. When a new board is produced which does populate these
devices, you are going to need a new .dts file. So you can put the
properties into that new file.

> 
> > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > us the schematics which clearly show extra long clock lines.
> 
> In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237

Pull low makes no difference to the 2ns RGMII delays.

> The tx_delay and rx_delay values were obtained using Rockchip's
> automatic scanning tool:
> https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf

Vendors get things wrong, including this. 'rgmii' means the PCB adds
the 2ns delay. Nearly every Rockchip board follows Rockchip broken
vendor recommendations, and then i come along, point out how it is
wrong, and ask for it to be fixed, before being merged to Mainline.

	Andrew

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Russell King (Oracle)]

On Tue, Oct 07, 2025 at 04:57:32PM +0200, Andrew Lunn wrote:
> On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> > Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
> > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > us the schematics which clearly show extra long clock lines.
> > 
> > In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> > just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
> 
> Pull low makes no difference to the 2ns RGMII delays.

To be clear, while the RXDLY and TXDLY are hardware strapping controls
the hardware configuration of the 2ns RGMII clock delays, the realtek
driver can (and does) override this according to the phy-mode property.
Thus hardware strapping makes no difference to Linux.

So, what we get at the RTL8211F PHY is:

	phy-mode	receive clock delay	transmit clock delay
	"rgmii"		0ns			0ns
	"rgmii-rxid"	2ns			0ns
	"rgmii-txid"	0ns			2ns
	"rgmii-id"	2ns			2ns

irrespective of RXDLY / TXDLY hardware strapping.

> > The tx_delay and rx_delay values were obtained using Rockchip's
> > automatic scanning tool:
> > https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> > https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> > https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> 
> Vendors get things wrong, including this. 'rgmii' means the PCB adds
> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> vendor recommendations, and then i come along, point out how it is
> wrong, and ask for it to be fixed, before being merged to Mainline.

Can we at least get the "tx_delay" and "rx_delay" DT properties (which
are register values) properly documented in the DT binding document?
I know from the driver code that a value of 0 means "no delay". Other
values add an unspecified delay - it is not obvious what any non-zero
value means, or what the default means.

This would help us understand what values such as:

	tx_delay = 0x3c or 0x4f

and

	rx_delay = 0x2f or 0x26

actually mean in terms of the resulting delay at the MAC.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v3 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1

[Russell King (Oracle)]

On Tue, Sep 30, 2025 at 01:19:21PM +0200, Diederik de Haas wrote:
> On Mon Sep 29, 2025 at 8:09 PM CEST, jjm2473 wrote:
> > I have another question. If there are reviewers or co-authors later,
> > do I need to add it to the commit message and send it again?
> > Or should the reviewer or co-author add the message and
> > continue to deliver the patch?
> 
> When you get a Reviewed-by tag, you should add that tag too to a new
> version. But there's no need to send a new version to just add those
> tags, the tooling used by maintainers picks those up themselves.

The only exception to this is if something changes in the patch
after the reviewed-by tag has been given - because changes mean
that the changes haven't been reviewed.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Quentin Schulz]

Hi Russel,

On 10/7/25 6:25 PM, Russell King (Oracle) wrote:
> On Tue, Oct 07, 2025 at 04:57:32PM +0200, Andrew Lunn wrote:
>> On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
>>> Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
>>>> Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
>>>> us the schematics which clearly show extra long clock lines.
>>>
>>> In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
>>> just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
>>> https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
>>
>> Pull low makes no difference to the 2ns RGMII delays.
> 
> To be clear, while the RXDLY and TXDLY are hardware strapping controls
> the hardware configuration of the 2ns RGMII clock delays, the realtek
> driver can (and does) override this according to the phy-mode property.
> Thus hardware strapping makes no difference to Linux.
> 
> So, what we get at the RTL8211F PHY is:
> 
> 	phy-mode	receive clock delay	transmit clock delay
> 	"rgmii"		0ns			0ns
> 	"rgmii-rxid"	2ns			0ns
> 	"rgmii-txid"	0ns			2ns
> 	"rgmii-id"	2ns			2ns
> 
> irrespective of RXDLY / TXDLY hardware strapping.
> 
>>> The tx_delay and rx_delay values were obtained using Rockchip's
>>> automatic scanning tool:
>>> https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
>>> https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
>>> https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
>>
>> Vendors get things wrong, including this. 'rgmii' means the PCB adds
>> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
>> vendor recommendations, and then i come along, point out how it is
>> wrong, and ask for it to be fixed, before being merged to Mainline.
> 
> Can we at least get the "tx_delay" and "rx_delay" DT properties (which
> are register values) properly documented in the DT binding document?
> I know from the driver code that a value of 0 means "no delay". Other
> values add an unspecified delay - it is not obvious what any non-zero
> value means, or what the default means.
> 
> This would help us understand what values such as:
> 
> 	tx_delay = 0x3c or 0x4f
> 
> and
> 
> 	rx_delay = 0x2f or 0x26
> 
> actually mean in terms of the resulting delay at the MAC.
> 

I couldn't figure out what they actually mean empirically, see 
https://lore.kernel.org/linux-rockchip/96d32ce8-394b-4454-8910-a66be2813588@cherry.de/

Without Rockchip's explanation on what this actually does, I'm not sure 
there's something we can do on this side.

Cheers,
Quentin

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[jjm2473]

Andrew Lunn <andrew@lunn.ch> 于2025年10月7日周二 22:57写道：
>
> On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> > Andrew Lunn <andrew@lunn.ch> 于2025年10月6日周一 23:51写道：
> > >
> > > > +&gmac0 {
> > > > +     phy-mode = "rgmii";
> > >
> > > Did i really miss this patch series in its earlier version, or did you
> > > ignore me?
> > >
> > > https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
> > >
> > > > +     tx_delay = <0x3c>;
> > > > +     rx_delay = <0x2f>;
> > >
> > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > us the schematics which clearly show extra long clock lines.
> > >
> > > > +/* Micro SD card slot is not mounted */
> > > > +&sdmmc0 {
> > > > +     max-frequency = <150000000>;
> > > > +     no-sdio;
> > > > +     no-mmc;
> > > > +     bus-width = <4>;
> > > > +     cap-mmc-highspeed;
> > > > +     cap-sd-highspeed;
> > > > +     disable-wp;
> > > > +     pinctrl-names = "default";
> > > > +     pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> > > > +     vmmc-supply = <&vcc3v3_sd>;
> > > > +     vqmmc-supply = <&vccio_sd>;
> > > > +     status = "disabled";
> > > > +};
> > > > +
> > > > +/* Wifi module is not mounted */
> > > > +&sdmmc2 {
> > >
> > > What do you mean by "not mounted"?
> > >
> > > Often you would say "not populated", to indicate the PCB has all the
> > > tracks in place, but the chip has simply not been soldered in place.
> > >
> > > Or is there a connector here, and nothing plugged into the connector?
> > >
> > >    Andrew
> >
> > Andrew:
> >  Hello! I ran `./scripts/get_maintainer.pl
> > patches-v4/v4-0003-arm64-dts-rockchip-add-LinkEase-EasePi-R1.patch`
> > to get maintainer list, and got:
> > ```
> > Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED
> > DEVICE TREE BINDINGS)
> > Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS,commit_signer:3/41=7%)
> > Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS)
> > Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC
> > support,commit_signer:43/41=100%,authored:4/41=10%,added_lines:12/117=10%,commit_signer:5/6=83%)
> > Quentin Schulz <quentin.schulz@cherry.de>
> > (commit_signer:10/41=24%,authored:8/41=20%,added_lines:63/117=54%)
> > Dragan Simic <dsimic@manjaro.org> (commit_signer:5/41=12%,commit_signer:1/6=17%)
> > FUKAUMI Naoki <naoki@radxa.com>
> > (commit_signer:3/41=7%,authored:3/41=7%,removed_lines:1/1=100%)
> > Peter Robinson <pbrobinson@gmail.com>
> > (added_lines:9/117=8%,commit_signer:1/6=17%,authored:1/6=17%)
> > Alexey Charkov <alchark@gmail.com> (added_lines:6/117=5%)
> > Diederik de Haas <didi.debian@cknow.org>
> > (commit_signer:4/6=67%,authored:3/6=50%)
> > Liangbin Lian <jjm2473@gmail.com> (commit_signer:1/6=17%,authored:1/6=17%)
> > Johan Jonker <jbx6244@gmail.com> (authored:1/6=17%)
> > devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
> > DEVICE TREE BINDINGS)
> > linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
> > linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
> > linux-kernel@vger.kernel.org (open list)
> > ```
> > your email address is not listed above.
>
> What i eventually found is that you posted v3 separately, and then
> threaded v4 to v2, which makes no sense.
>
> Please always start a new thread for each patchset.
>
> > > What do you mean by "not mounted"?
> > >
> > > Often you would say "not populated", to indicate the PCB has all the
> > > tracks in place, but the chip has simply not been soldered in place.
> > >
> > > Or is there a connector here, and nothing plugged into the connector?
> >
> > The chip/slot has not been soldered. So here should be "not
> > populated", forgive my poor English.
>
> Thanks for the clarification. I'm not sure it is worth adding these DT
> properties. When a new board is produced which does populate these
> devices, you are going to need a new .dts file. So you can put the
> properties into that new file.
>
> >
> > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > us the schematics which clearly show extra long clock lines.
> >
> > In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> > just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
>
> Pull low makes no difference to the 2ns RGMII delays.
>
> > The tx_delay and rx_delay values were obtained using Rockchip's
> > automatic scanning tool:
> > https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> > https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> > https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
>
> Vendors get things wrong, including this. 'rgmii' means the PCB adds
> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> vendor recommendations, and then i come along, point out how it is
> wrong, and ask for it to be fixed, before being merged to Mainline.
>
>         Andrew

Andrew:
 Hello!

>
> What i eventually found is that you posted v3 separately, and then
> threaded v4 to v2, which makes no sense.
>

This is v2 link
https://lore.kernel.org/all/20250925092037.13582-1-jjm2473@gmail.com/
.
I don't see 'v4' in there. I have no idea why you see 'v4', can you
please share a link?

This is v3 link
https://lore.kernel.org/all/20250929065714.27741-1-jjm2473@gmail.com/
.
I don't see threading issue.
I use `git send-email --to '***' --cc '***' patches-v3` to send email,
should be OK.
(`patches-v3` is a folder contains patches generaterated by `git
format-patch --base=master --cover-letter -v3 HEAD -3 -o patches-v3`).

> When a new board is produced which does populate these
> devices, you are going to need a new .dts file. So you can put the
> properties into that new file.

These two nodes just describe the gpio and regulator found in the schematic.
If some users solder these connectors or modules themselves,
they only need to change the status to ok and they can use them.
If this will cause confusion, I can delete these two nodes.

> Vendors get things wrong, including this. 'rgmii' means the PCB adds
> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> vendor recommendations, and then i come along, point out how it is
> wrong, and ask for it to be fixed, before being merged to Mainline.

I will try `rgmii-id` and rescan {tx|rx}_delay, just like
https://lore.kernel.org/all/20250925092923.2184187-3-heiko@sntech.de/

I also notice that you suggest use {tx|rx}-internal-delay-ps instead
of  {tx|rx}_delay in
https://lore.kernel.org/all/e4d3127b-c879-4931-9ea0-de7449bc508c@lunn.ch/ ,
but I think this depends on stmmac driver.

  Liangbin Lian

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Andrew Lunn]

> I also notice that you suggest use {tx|rx}-internal-delay-ps instead
> of  {tx|rx}_delay in
> https://lore.kernel.org/all/e4d3127b-c879-4931-9ea0-de7449bc508c@lunn.ch/ ,
> but I think this depends on stmmac driver.

It depends on the driver implementing those standard properties. But
as pointed out elsewhere, tx|rx-delay are magic, nobody knows what
they do, so it is hard to implement the standard properties to replace
them.

     Andrew

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Russell King (Oracle)]

On Wed, Oct 08, 2025 at 01:29:57AM +0800, jjm2473 wrote:
> > Vendors get things wrong, including this. 'rgmii' means the PCB adds
> > the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> > vendor recommendations, and then i come along, point out how it is
> > wrong, and ask for it to be fixed, before being merged to Mainline.
> 
> I will try `rgmii-id` and rescan {tx|rx}_delay, just like
> https://lore.kernel.org/all/20250925092923.2184187-3-heiko@sntech.de/

The current situation is...

https://lore.kernel.org/r/20240304084612.711678-2-ukleinek@debian.org

Notice that the tx_delay and rx_delay are removed - because with
"rgmii-id" the stmmac glue driver ignores the delay values.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[jjm2473]

Russell King (Oracle) <linux@armlinux.org.uk> 于2025年10月8日周三 02:48写道：
>
> On Wed, Oct 08, 2025 at 01:29:57AM +0800, jjm2473 wrote:
> > > Vendors get things wrong, including this. 'rgmii' means the PCB adds
> > > the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> > > vendor recommendations, and then i come along, point out how it is
> > > wrong, and ask for it to be fixed, before being merged to Mainline.
> >
> > I will try `rgmii-id` and rescan {tx|rx}_delay, just like
> > https://lore.kernel.org/all/20250925092923.2184187-3-heiko@sntech.de/
>
> The current situation is...
>
> https://lore.kernel.org/r/20240304084612.711678-2-ukleinek@debian.org
>
> Notice that the tx_delay and rx_delay are removed - because with
> "rgmii-id" the stmmac glue driver ignores the delay values.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

I  change phy-mode to "rgmii-id", and remove {tx|rx}_delay, it works fine!
Will apply that to the next version.

Thanks!

  Liangbin Lian

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Alexey Charkov]

On Tue, Oct 7, 2025 at 10:32 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > I also notice that you suggest use {tx|rx}-internal-delay-ps instead
> > of  {tx|rx}_delay in
> > https://lore.kernel.org/all/e4d3127b-c879-4931-9ea0-de7449bc508c@lunn.ch/ ,
> > but I think this depends on stmmac driver.
>
> It depends on the driver implementing those standard properties. But
> as pointed out elsewhere, tx|rx-delay are magic, nobody knows what
> they do, so it is hard to implement the standard properties to replace
> them.

FWIW, the TRM for Rockchip RK3576 specifies that the values in
tx|rx-delay control the number of delay elements in the internal
delayline on the transmit and receive clocks, respectively (up to 200
each). There is no mention of the actual delay each delay element
introduces, though, so that doesn't get us much closer.

Best regards,
Alexey

Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

[Andrew Lunn]

> FWIW, the TRM for Rockchip RK3576 specifies that the values in
> tx|rx-delay control the number of delay elements in the internal
> delayline on the transmit and receive clocks, respectively (up to 200
> each).

200 is interesting:

  tx_delay:
    description: Delay value for TXD timing.
    $ref: /schemas/types.yaml#/definitions/uint32
    minimum: 0
    maximum: 0x7F


200 != 0x7f

But i don't think the driver does any validation, so its not too
important.

    Andrew