| Message ID | 20241210163615.120594-1-sebastian.reichel@collabora.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v1,1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B | expand |
Hi Sebastian,
Thank you very much for your work!
$ cat
/sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
1500000
1500000
1
USB
C [PD] PD_PPS
20000000
20000000
20000000
$ cat
/sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
5000000
5000000
1
USB
C PD [PD_PPS]
20000000
20000000
20000000
$ ls /sys/class/udc/
fc000000.usb
I can configure it as CDC-NCM and host detects it.
But I could not use it as a HOST port. How to use it?
some minor nitpick is below:
On 12/11/24 01:36, Sebastian Reichel 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.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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";
typec_vin by schematic.
> + 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>;
typec_vin.
> };
>
> 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 {
Is "usbc0" label necessary?
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usbc0_int>;
cc_int_l by schematic.
> + vbus-supply = <&vcc12v_dcin>;
typec_vin
> + /*
> + * 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.
... resets "the" whole board.
> + */
> + status = "fail";
> +
> + usb_con: connector {
Is "usb_con" label necessary?
> + 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 {
cc_int_l
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> + 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";
> };
Hi, two correction, On 12/11/24 07:10, FUKAUMI Naoki wrote: > Hi Sebastian, > > Thank you very much for your work! > > $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/ > {current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now} > 1500000 > 1500000 > 1 > USB > C [PD] PD_PPS > 20000000 > 20000000 > 20000000 > > $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/ > {current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now} > 5000000 > 5000000 > 1 > USB > C PD [PD_PPS] > 20000000 > 20000000 > 20000000 > > $ ls /sys/class/udc/ > fc000000.usb > > I can configure it as CDC-NCM and host detects it. > But I could not use it as a HOST port. How to use it? > > some minor nitpick is below: > > On 12/11/24 01:36, Sebastian Reichel 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. >> >> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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"; > > typec_vin by schematic. > >> + 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>; > > typec_vin. > >> }; >> 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 { > > Is "usbc0" label necessary? please ignore, I noticed it's necessary for my work ;) > >> + compatible = "fcs,fusb302"; >> + reg = <0x22>; >> + interrupt-parent = <&gpio3>; >> + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&usbc0_int>; > > cc_int_l by schematic. > >> + vbus-supply = <&vcc12v_dcin>; > > typec_vin > >> + /* >> + * 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. > > ... resets "the" whole board. > >> + */ >> + status = "fail"; >> + >> + usb_con: connector { > > Is "usb_con" label necessary? it's necessary for my work, but I think "usbc0_con" is consistent with others. Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. >> + 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 { > > cc_int_l > > Best regards, > > -- > FUKAUMI Naoki > Radxa Computer (Shenzhen) Co., Ltd. > >> + 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"; >> }; >
Hello Naoki, On Wed, Dec 11, 2024 at 07:10:55AM +0900, FUKAUMI Naoki wrote: > Hi Sebastian, > > Thank you very much for your work! > > $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now} > 1500000 > 1500000 > 1 > USB > C [PD] PD_PPS > 20000000 > 20000000 > 20000000 > > $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now} > 5000000 > 5000000 > 1 > USB > C PD [PD_PPS] > 20000000 > 20000000 > 20000000 > > $ ls /sys/class/udc/ > fc000000.usb > > I can configure it as CDC-NCM and host detects it. > But I could not use it as a HOST port. How to use it? You can switch between host and peripheral for Type-C ports like this depending on the remote sides capabilities: * echo host > /sys/class/typec/<port>/data_role * echo device > /sys/class/typec/<port>/data_role I tested this with a USB-C hub connected to the port, which works in host mode. > some minor nitpick is below: > > On 12/11/24 01:36, Sebastian Reichel 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. > > > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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"; > > typec_vin by schematic. Ack. Will update in v2. > > + 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>; > > typec_vin. > > > }; > > 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 { > > Is "usbc0" label necessary? no, but does it hurt? > > + compatible = "fcs,fusb302"; > > + reg = <0x22>; > > + interrupt-parent = <&gpio3>; > > + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&usbc0_int>; > > cc_int_l by schematic. Ack. I intentionally switched away from this naming, since cc prefix is imho a way worse prefix than usbc0. The _l suffix just means active low, which is already encoded in DT. But I don't have a strong opinion and can fix this in v2. > > + vbus-supply = <&vcc12v_dcin>; > > typec_vin > > > + /* > > + * 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. > > ... resets "the" whole board. Ack. > > > + */ > > + status = "fail"; > > + > > + usb_con: connector { > > Is "usb_con" label necessary? No. It should either be changed to "usbc0_con" or removed. In general I tend to add some labels when they might be needed by something in the future. They are more or less free anyways. -- Sebastian
Hi Sebastian, On 12/11/24 08:08, Sebastian Reichel wrote: > Hello Naoki, > > On Wed, Dec 11, 2024 at 07:10:55AM +0900, FUKAUMI Naoki wrote: >> Hi Sebastian, >> >> Thank you very much for your work! >> >> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now} >> 1500000 >> 1500000 >> 1 >> USB >> C [PD] PD_PPS >> 20000000 >> 20000000 >> 20000000 >> >> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now} >> 5000000 >> 5000000 >> 1 >> USB >> C PD [PD_PPS] >> 20000000 >> 20000000 >> 20000000 >> >> $ ls /sys/class/udc/ >> fc000000.usb >> >> I can configure it as CDC-NCM and host detects it. >> But I could not use it as a HOST port. How to use it? > > You can switch between host and peripheral for Type-C ports like > this depending on the remote sides capabilities: > > * echo host > /sys/class/typec/<port>/data_role > * echo device > /sys/class/typec/<port>/data_role thanks! I tested both data_role and both orientation. all works. > I tested this with a USB-C hub connected to the port, which works > in host mode. > >> some minor nitpick is below: >> >> On 12/11/24 01:36, Sebastian Reichel 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. >>> >>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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"; >> >> typec_vin by schematic. > > Ack. Will update in v2. > >>> + regulator-always-on; >>> + regulator-boot-on; >>> + regulator-min-microvolt = <12000000>; >>> + regulator-max-microvolt = <12000000>; both microvolt line can be removed. >>> + }; >>> + >>> 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>; >> >> typec_vin. >> >>> }; >>> 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 { >> >> Is "usbc0" label necessary? > > no, but does it hurt? sorry, please keep it. >>> + compatible = "fcs,fusb302"; >>> + reg = <0x22>; >>> + interrupt-parent = <&gpio3>; >>> + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>; >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&usbc0_int>; >> >> cc_int_l by schematic. > > Ack. I intentionally switched away from this naming, since cc prefix > is imho a way worse prefix than usbc0. The _l suffix just means > active low, which is already encoded in DT. > > But I don't have a strong opinion and can fix this in v2. > >>> + vbus-supply = <&vcc12v_dcin>; >> >> typec_vin >> >>> + /* >>> + * 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. >> >> ... resets "the" whole board. > > Ack. > >> >>> + */ >>> + status = "fail"; >>> + >>> + usb_con: connector { >> >> Is "usb_con" label necessary? > > No. It should either be changed to "usbc0_con" or removed. In > general I tend to add some labels when they might be needed by > something in the future. They are more or less free anyways. +1 for "usbc0_con". Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. > -- Sebastian
Sorry, I forgot to write one thing... On 12/11/24 01:36, Sebastian Reichel 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. > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: FUKAUMI Naoki <naoki@radxa.com> -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. > --- > .../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"; > };
Hi Sebastian, Sorry for many emails... I got random reboot during booting kernel/userland... Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. On 12/11/24 09:06, FUKAUMI Naoki wrote: > Sorry, I forgot to write one thing... > > On 12/11/24 01:36, Sebastian Reichel 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. >> >> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> > > Tested-by: FUKAUMI Naoki <naoki@radxa.com> > > -- > FUKAUMI Naoki > Radxa Computer (Shenzhen) Co., Ltd. > >> --- >> .../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"; >> }; >
Hi Naoki,
On Wed, Dec 11, 2024 at 09:40:13AM +0900, FUKAUMI Naoki wrote:
> I got random reboot during booting kernel/userland...
That is probably related to USB-C PD communication resulting in
another hard reset :( Can you try to get some tcpm_log() data
from debugfs while the board is powered from the GPIO header or
PoE?
Greetings,
-- Sebastian
Hi Sebastian, On 12/13/24 04:20, Sebastian Reichel wrote: > Hi Naoki, > > On Wed, Dec 11, 2024 at 09:40:13AM +0900, FUKAUMI Naoki wrote: >> I got random reboot during booting kernel/userland... > > That is probably related to USB-C PD communication resulting in > another hard reset :( Can you try to get some tcpm_log() data > from debugfs while the board is powered from the GPIO header or > PoE? Unfortunately I don't have such a tool... Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. > Greetings, > > -- Sebastian
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"; };
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. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> --- .../boot/dts/rockchip/rk3588-rock-5b.dts | 121 ++++++++++++++++++ 1 file changed, 121 insertions(+)