lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <njeivdzwyy6qxome77asapmi3a3l34mpauk366f6zgpt2mvorz@ra77f5vjd5lf>
Date: Sat, 1 Mar 2025 23:42:51 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Andy Yan <andyshrk@....com>
Cc: Heiko Stuebner <heiko@...ech.de>, Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	FUKAUMI Naoki <naoki@...xa.com>, linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B

Hello Andy,

On Sat, Mar 01, 2025 at 08:38:01PM +0800, Andy Yan wrote:
> At 2024-12-11 00:36:01, "Sebastian Reichel" <sebastian.reichel@...labora.com> wrote:
> >Add hardware description for the USB-C port in the Radxa Rock 5 Model B.
> >This describes the OHCI, EHCI and XHCI USB parts, but not yet the
> >DisplayPort AltMode (bindings are not yet upstream).
> >
> >The fusb302 node is marked with status "fail", since the board is usually
> >powered through the USB-C port. Handling of errors can result in hard
> >resets, which removed the bus power for some time resulting in a board
> >reset.
> >
> >The main problem is that devices are supposed to interact with the
> >power-supply within 5 seconds after the plug event according to the
> >USB PD specification. This is more or less impossible to achieve when
> >the kernel is the first software communicating with the power-supply.
> >
> >Recent U-Boot (v2025.01) will start doing USB-PD communication, which
> >solves this issue. Upstream U-Boot doing USB-PD communication will also
> >set the fusb302 node status to "okay". That way booting a kernel with
> >the updated DT on an old U-Boot avoids a reset loop.
> 
> Do you have any plans to continue working on this patch?
> I've been working on enabling the DP Alt Mode output recently
> and think the Rock 5b is a good starting point。

This is still on my radar. I recently send an updates U-Boot series
with some TCPM improvements:

https://lore.kernel.org/u-boot/20250226184506.64114-1-sebastian.reichel@collabora.com/

Even with that there are more issues resulting in hard resets
happening in some circumstances (if they are happening depends a lot
on the specific powre supply being used). I'm still looking for the
root cause of these. It's also hard to tell when it is a good time
to apply this patch. Some people will probably see a regression due
to using power-supplies diverging too far from the standard :/

Greetings,

-- Sebastian

>      
> >
> >Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> >---
> > .../boot/dts/rockchip/rk3588-rock-5b.dts      | 121 ++++++++++++++++++
> > 1 file changed, 121 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >index d597112f1d5b..cb5990df6ccb 100644
> >--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >@@ -5,6 +5,7 @@
> > #include <dt-bindings/gpio/gpio.h>
> > #include <dt-bindings/leds/common.h>
> > #include <dt-bindings/soc/rockchip,vop2.h>
> >+#include <dt-bindings/usb/pd.h>
> > #include "rk3588.dtsi"
> > 
> > / {
> >@@ -84,6 +85,15 @@ rfkill-bt {
> > 		shutdown-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_HIGH>;
> > 	};
> > 
> >+	vcc12v_dcin: regulator-vcc12v-dcin {
> >+		compatible = "regulator-fixed";
> >+		regulator-name = "vcc12v_dcin";
> >+		regulator-always-on;
> >+		regulator-boot-on;
> >+		regulator-min-microvolt = <12000000>;
> >+		regulator-max-microvolt = <12000000>;
> >+	};
> >+
> > 	vcc3v3_pcie2x1l0: regulator-vcc3v3-pcie2x1l0 {
> > 		compatible = "regulator-fixed";
> > 		enable-active-high;
> >@@ -142,6 +152,7 @@ vcc5v0_sys: regulator-vcc5v0-sys {
> > 		regulator-boot-on;
> > 		regulator-min-microvolt = <5000000>;
> > 		regulator-max-microvolt = <5000000>;
> >+		vin-supply = <&vcc12v_dcin>;
> > 	};
> > 
> > 	vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
> >@@ -264,6 +275,67 @@ regulator-state-mem {
> > 	};
> > };
> > 
> >+&i2c4 {
> >+	pinctrl-names = "default";
> >+	pinctrl-0 = <&i2c4m1_xfer>;
> >+	status = "okay";
> >+
> >+	usbc0: usb-typec@22 {
> >+		compatible = "fcs,fusb302";
> >+		reg = <0x22>;
> >+		interrupt-parent = <&gpio3>;
> >+		interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
> >+		pinctrl-names = "default";
> >+		pinctrl-0 = <&usbc0_int>;
> >+		vbus-supply = <&vcc12v_dcin>;
> >+		/*
> >+		 * When the board is starting to send power-delivery messages
> >+		 * too late (5 seconds according to the specification), the
> >+		 * power-supply reacts with a hard-reset. That removes the
> >+		 * power from VBUS for some time, which resets te whole board.
> >+		 */
> >+		status = "fail";
> >+
> >+		usb_con: connector {
> >+			compatible = "usb-c-connector";
> >+			label = "USB-C";
> >+			data-role = "dual";
> >+			power-role = "sink";
> >+			try-power-role = "sink";
> >+			op-sink-microwatt = <1000000>;
> >+			sink-pdos =
> >+				<PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>,
> >+				<PDO_VAR(5000, 20000, 5000)>;
> >+
> >+			ports {
> >+				#address-cells = <1>;
> >+				#size-cells = <0>;
> >+
> >+				port@0 {
> >+					reg = <0>;
> >+					usbc0_role_sw: endpoint {
> >+						remote-endpoint = <&dwc3_0_role_switch>;
> >+					};
> >+				};
> >+
> >+				port@1 {
> >+					reg = <1>;
> >+					usbc0_orien_sw: endpoint {
> >+						remote-endpoint = <&usbdp_phy0_orientation_switch>;
> >+					};
> >+				};
> >+
> >+				port@2 {
> >+					reg = <2>;
> >+					dp_altmode_mux: endpoint {
> >+						remote-endpoint = <&usbdp_phy0_dp_altmode_mux>;
> >+					};
> >+				};
> >+			};
> >+		};
> >+	};
> >+};
> >+
> > &i2c6 {
> > 	status = "okay";
> > 
> >@@ -423,6 +495,10 @@ usb {
> > 		vcc5v0_host_en: vcc5v0-host-en {
> > 			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
> > 		};
> >+
> >+		usbc0_int: usbc0-int {
> >+			rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
> >+		};
> > 	};
> > };
> > 
> >@@ -835,6 +911,14 @@ &uart2 {
> > 	status = "okay";
> > };
> > 
> >+&u2phy0 {
> >+	status = "okay";
> >+};
> >+
> >+&u2phy0_otg {
> >+	status = "okay";
> >+};
> >+
> > &u2phy1 {
> > 	status = "okay";
> > };
> >@@ -866,6 +950,29 @@ &usbdp_phy1 {
> > 	status = "okay";
> > };
> > 
> >+&usbdp_phy0 {
> >+	mode-switch;
> >+	orientation-switch;
> >+	sbu1-dc-gpios = <&gpio4 RK_PA6 GPIO_ACTIVE_HIGH>;
> >+	sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
> >+	status = "okay";
> >+
> >+	port {
> >+		#address-cells = <1>;
> >+		#size-cells = <0>;
> >+
> >+		usbdp_phy0_orientation_switch: endpoint@0 {
> >+			reg = <0>;
> >+			remote-endpoint = <&usbc0_orien_sw>;
> >+		};
> >+
> >+		usbdp_phy0_dp_altmode_mux: endpoint@1 {
> >+			reg = <1>;
> >+			remote-endpoint = <&dp_altmode_mux>;
> >+		};
> >+	};
> >+};
> >+
> > &usb_host0_ehci {
> > 	status = "okay";
> > };
> >@@ -874,6 +981,20 @@ &usb_host0_ohci {
> > 	status = "okay";
> > };
> > 
> >+&usb_host0_xhci {
> >+	usb-role-switch;
> >+	status = "okay";
> >+
> >+	port {
> >+		#address-cells = <1>;
> >+		#size-cells = <0>;
> >+
> >+		dwc3_0_role_switch: endpoint {
> >+			remote-endpoint = <&usbc0_role_sw>;
> >+		};
> >+	};
> >+};
> >+
> > &usb_host1_ehci {
> > 	status = "okay";
> > };
> >-- 
> >2.45.2
> >

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ