Hi Sebastian,

Thanks for sharing the details.

On Sat, 3 Jan 2026 at 19:54, Sebastian Reichel
[off-list ref] wrote:

Hello Anand,

On Sat, Jan 03, 2026 at 02:01:16PM +0530, Anand Moon wrote:

quoted

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,

quoted

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.

quoted

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/ (local)

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

Yes, but it's related I2C protocol.

quoted

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