Hi All

On the Radxa Rock 5B, the system occasionally experiences intermittent
hard resets during the boot process. Initially, I suspected a power supply
issue, but further investigation points to the Type-C fusb302 module as
the cause.

Specifically, probing or reloading the fusb302 module triggers a hard reset,
which can result in immediate power loss and a reboot.

[root@rockpi-5b ~]# rmmod fusb302
[root@rockpi-5b ~]# lsmod | grep  fusb302
[root@rockpi-5b ~]# modprobe fusb302
[root@rockpi-5b ~]# [ 3389.031608][ T7143] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.
[ 3390.030444][ T7143] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.

I attempted to trace the issue using ftrace but was unable to pinpoint the
root cause. The problem appears to originate either from the I2C controller
or the PMIC reset.

I have identified a potential workaround involving the I2C SCL debounce settings
for the RK3588 and submitted a patch here:

[1] https://lore.kernel.org/all/20260103052506.6743-1-linux.amoon@gmail.com/

Please note that the submitted changes address a minor aspect but do not fully
resolve the underlying issue.

Thanks
-Anand

Anand Moon (3):
  arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Correct Type-C pin bias
    settings
  arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Fix USB host phy-supply
    on Rock 5b-5bp-5t SbC
  usb: typec: fusb302: Switch to threaded interrupt handler

 arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 7 +++----
 drivers/usb/typec/tcpm/fusb302.c                        | 7 ++++---
 2 files changed, 7 insertions(+), 7 deletions(-)


base-commit: 805f9a061372164d43ddef771d7cd63e3ba6d845
-- 
2.50.1

Hello Anand,

On Sat, Jan 03, 2026 at 02:01:16PM +0530, Anand Moon wrote:
> On the Radxa Rock 5B, the system occasionally experiences intermittent
> hard resets during the boot process. Initially, I suspected a power supply
> issue, but further investigation points to the Type-C fusb302 module as
> the cause.
> 
> Specifically, probing or reloading the fusb302 module triggers a hard reset,
> which can result in immediate power loss and a reboot.
> 
> [root@rockpi-5b ~]# rmmod fusb302
> [root@rockpi-5b ~]# lsmod | grep  fusb302
> [root@rockpi-5b ~]# modprobe fusb302
> [root@rockpi-5b ~]# [ 3389.031608][ T7143] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.
> [ 3390.030444][ T7143] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.

If you see this message the TypeC port manager (TCPM) state machine
reached the hard reset error state. A USB-PD hard reset involves
removing VBUS for a short time, which effectively removes the board
power on ROCK 5B. Unfortunately the situation is quite complex :)

> I attempted to trace the issue using ftrace but was unable to
> pinpoint the root cause. The problem appears to originate either
> from the I2C controller or the PMIC reset.

I2C and PMIC are not at fault. This is all about USB-PD
communication itself.

> I have identified a potential workaround involving the I2C SCL debounce settings
> for the RK3588 and submitted a patch here:
> 
> [1] https://lore.kernel.org/all/20260103052506.6743-1-linux.amoon@gmail.com/

This is most likely a red herring and just slightly changing timings
in the USB PD communication.

> Please note that the submitted changes address a minor aspect but do not fully
> resolve the underlying issue.

I don't expect any fix from this series regarding your problem. Also
I suggest having a look at my talk at the Linux Plumbers Conference
from last month where I discussed this issue :)

slides: https://lpc.events/event/19/contributions/2156/attachments/1784/3861/improving-stability-for-TCPM-using-boards-that-are-not-self-powered.pdf
video: https://www.youtube.com/watch?v=DmLsePJoH8I

Something that might be sensible to do on your end is figure out
*how* the state machine ended up in the error state and check if
we can avoid it. The related code for that lives in
drivers/usb/typec/tcpm/tcpm.c and quite complex. I use the
following two patches to ease debugging:

 * https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/6edc68e3c0ec4c209b5e96b848e17201059ce9ee
 * https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/8ca8b1d6ee36e80f794bcf351a8b78d5a96daf06

Combined with CONFIG_DYNAMIC_DEBUG=y and booting with the following
kernel arguments: loglevel=8 tcpm.dyndbg="+p" fusb302.dyndbg="+p"

Greetings,

-- Sebastian

> 
> Thanks
> -Anand
> 
> Anand Moon (3):
>   arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Correct Type-C pin bias
>     settings
>   arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Fix USB host phy-supply
>     on Rock 5b-5bp-5t SbC
>   usb: typec: fusb302: Switch to threaded interrupt handler
> 
>  arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 7 +++----
>  drivers/usb/typec/tcpm/fusb302.c                        | 7 ++++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> 
> base-commit: 805f9a061372164d43ddef771d7cd63e3ba6d845
> -- 
> 2.50.1
> 

Hi Sebastian,

Thanks for sharing the details.

On Sat, 3 Jan 2026 at 19:54, Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> Hello Anand,
>
> On Sat, Jan 03, 2026 at 02:01:16PM +0530, Anand Moon wrote:
> > On the Radxa Rock 5B, the system occasionally experiences intermittent
> > hard resets during the boot process. Initially, I suspected a power supply
> > issue, but further investigation points to the Type-C fusb302 module as
> > the cause.
> >
> > Specifically, probing or reloading the fusb302 module triggers a hard reset,
> > which can result in immediate power loss and a reboot.
> >
> > [root@rockpi-5b ~]# rmmod fusb302
> > [root@rockpi-5b ~]# lsmod | grep  fusb302
> > [root@rockpi-5b ~]# modprobe fusb302
> > [root@rockpi-5b ~]# [ 3389.031608][ T7143] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.
> > [ 3390.030444][ T7143] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.
>
> If you see this message the TypeC port manager (TCPM) state machine
> reached the hard reset error state. A USB-PD hard reset involves
> removing VBUS for a short time, which effectively removes the board
> power on ROCK 5B. Unfortunately the situation is quite complex :)
>
I completely understand this issue,
> > I attempted to trace the issue using ftrace but was unable to
> > pinpoint the root cause. The problem appears to originate either
> > from the I2C controller or the PMIC reset.
>
> I2C and PMIC are not at fault. This is all about USB-PD
> communication itself.
>
> > I have identified a potential workaround involving the I2C SCL debounce settings
> > for the RK3588 and submitted a patch here:
> >
> > [1] https://lore.kernel.org/all/20260103052506.6743-1-linux.amoon@gmail.com/
>
> This is most likely a red herring and just slightly changing timings
> in the USB PD communication.
Yes, but it's related I2C protocol.
>
> > Please note that the submitted changes address a minor aspect but do not fully
> > resolve the underlying issue.
>
> I don't expect any fix from this series regarding your problem. Also
> I suggest having a look at my talk at the Linux Plumbers Conference
> from last month where I discussed this issue :)
>
> slides: https://lpc.events/event/19/contributions/2156/attachments/1784/3861/improving-stability-for-TCPM-using-boards-that-are-not-self-powered.pdf
> video: https://www.youtube.com/watch?v=DmLsePJoH8I
>
It's a great talk. I understood the issue much better

I have understood the previous discussion regarding the reset failure.
In this specific case, the Type-C power is controlled by the USB 3.0 and USB 2.0
host controller power domains, I feel so.

> Something that might be sensible to do on your end is figure out
> *how* the state machine ended up in the error state and check if
> we can avoid it. The related code for that lives in
> drivers/usb/typec/tcpm/tcpm.c and quite complex. I use the
> following two patches to ease debugging:
>
>  * https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/6edc68e3c0ec4c209b5e96b848e17201059ce9ee
>  * https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/8ca8b1d6ee36e80f794bcf351a8b78d5a96daf06
>
> Combined with CONFIG_DYNAMIC_DEBUG=y and booting with the following
> kernel arguments: loglevel=8 tcpm.dyndbg="+p" fusb302.dyndbg="+p"
>
Yep, I have enabled this, but I could not find many details

> Greetings,
>
> -- Sebastian
>
Thanks
-Anand