[PATCH v1 0/3] Typc fusb302 powerloss issue on Radxa Rock 5b

[Sebastian Reichel]

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 at rockpi-5b ~]# rmmod fusb302
> [root at rockpi-5b ~]# lsmod | grep  fusb302
> [root at rockpi-5b ~]# modprobe fusb302
> [root at 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260103/f0cf93cc/attachment-0001.sig>