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

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

[Anand Moon]

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

[PATCH v1 1/3] arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Correct Type-C pin bias settings

[Anand Moon]

As pre FUSB302 datasheet interrupt line (INT_N) is an open-drain,
active-low signal. It requires a pull-up resistor to maintain a stable
high state when deasserted. Similarly, the TYPEC5V_PWREN_H enable signal
requires a pull-down resistor to ensure it defaults to a low state,
preventing unintended power delivery during the boot sequence.

Update the pinctrl entries to use pcfg_pull_up for usbc0_int and
pcfg_pull_down for vbus5v0_typec_en to align with the hardware's
electrical requirements.

Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Fixes: 67b2c15d8fb3 ("arm64: dts: rockchip: add USB-C support for ROCK 5B/5B+/5T")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v1: As per the shematics CC_INT_L interrupt pin is GPIO3_B4_u
    As per the shematics TYPEC5V_PWREN_H pin is GPIO2_B6_d
---
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index b3e76ad2d869..0cd8ac7bf538 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -537,11 +537,11 @@ pcie3_vcc3v3_en: pcie3-vcc3v3-en {
 
 	usb {
 		usbc0_int: usbc0-int {
-			rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+			rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
 		};
 
 		vbus5v0_typec_en: vbus5v0-typec-en {
-			rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+			rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
 		};
 	};
 };
-- 
2.50.1

Re: [PATCH v1 1/3] arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Correct Type-C pin bias settings

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

Hi,

On Sat, Jan 03, 2026 at 02:01:17PM +0530, Anand Moon wrote:
> As pre FUSB302 datasheet interrupt line (INT_N) is an open-drain,
> active-low signal. It requires a pull-up resistor to maintain a stable
> high state when deasserted. Similarly, the TYPEC5V_PWREN_H enable signal
> requires a pull-down resistor to ensure it defaults to a low state,
> preventing unintended power delivery during the boot sequence.
> 
> Update the pinctrl entries to use pcfg_pull_up for usbc0_int and
> pcfg_pull_down for vbus5v0_typec_en to align with the hardware's
> electrical requirements.
> 
> Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
> Fixes: 67b2c15d8fb3 ("arm64: dts: rockchip: add USB-C support for ROCK 5B/5B+/5T")
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> v1: As per the shematics CC_INT_L interrupt pin is GPIO3_B4_u
>     As per the shematics TYPEC5V_PWREN_H pin is GPIO2_B6_d
> ---

Checking the schematics:

5B v1.45 - CC_INT_L - R2613 10K pull-up resistor
5B v1.45 - TYPEC5V_PWREN_H - GPIO is effectively unused because R95035 is NC

5B+ v1.2 - CC_INT_L - R2613 10K pull-up resistor
5B+ v1.2 - TYPEC5V_PWREN_H - R163 100K pull-down resistor

5T v1.2 - CC_INT_L - R2613 10K pull-up resistor
5T v1.2 - TYPEC5V_PWREN_H - R163 100K pull-down resistor

TLDR: All GPIOs have pull resistors in discrete hardware and do not
need them muxed in the SoC.

Greetings,

-- Sebastian

>  arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
> index b3e76ad2d869..0cd8ac7bf538 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
> @@ -537,11 +537,11 @@ pcie3_vcc3v3_en: pcie3-vcc3v3-en {
>  
>  	usb {
>  		usbc0_int: usbc0-int {
> -			rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
> +			rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
>  		};
>  
>  		vbus5v0_typec_en: vbus5v0-typec-en {
> -			rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> +			rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
>  		};
>  	};
>  };
> -- 
> 2.50.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v1 2/3] arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Fix USB host phy-supply on Rock 5b-5bp-5t SbC

[Anand Moon]

The USB host USB2 and USB3 on the Rock 5B, 5BP, and 5T is powered by the
USB_HOST_PWREN_H gpio pin which is used to enable vcc5v0_host host
regulator which ensures proper power sequencing and management for onboard
Double-USB-HOST.

Update the u2phy2_host node to reference the correct phy-supply.

Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index 0cd8ac7bf538..886d788572fc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -981,8 +981,7 @@ &u2phy2 {
 };
 
 &u2phy2_host {
-	/* connected to USB hub, which is powered by vcc5v0_sys */
-	phy-supply = <&vcc5v0_sys>;
+	phy-supply = <&vcc5v0_host>;
 	status = "okay";
 };
 
-- 
2.50.1

Re: [PATCH v1 2/3] arm64: dts: rockchip: rk3588-rock-5b-5bp-5t: Fix USB host phy-supply on Rock 5b-5bp-5t SbC

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

Hi,

On Sat, Jan 03, 2026 at 02:01:18PM +0530, Anand Moon wrote:
> The USB host USB2 and USB3 on the Rock 5B, 5BP, and 5T is powered by the
> USB_HOST_PWREN_H gpio pin which is used to enable vcc5v0_host host
> regulator which ensures proper power sequencing and management for onboard
> Double-USB-HOST.
> 
> Update the u2phy2_host node to reference the correct phy-supply.
> 
> Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---

u2phy2_host is connected to an onboard USB hub chip, which is
powered by &vcc5v0_sys as the comment says.

You can see this on page 9 of the v1.45 ROCK 5B schematics (page
name USB2HUB). The usb hub chip uses VCC5V0_SYS + VCC_3V3_S0 and is
connected to USB20_HOST0_DP, USB20_HOST0_DM. The related USB
controller for that in the upstream DT is &usb_host0_ehci, which
in turn is using &u2phy2_host. Thus at least for the ROCK 5B the
existing DT is correct. Properly describing the downstream port
VBUS regulator would require something like the following series:

https://lore.kernel.org/all/20250911-v6-16-topic-usb-onboard-dev-v4-0-1af288125d74@pengutronix.de/

Greetings,

-- Sebastian

>  arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
> index 0cd8ac7bf538..886d788572fc 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
> @@ -981,8 +981,7 @@ &u2phy2 {
>  };
>  
>  &u2phy2_host {
> -	/* connected to USB hub, which is powered by vcc5v0_sys */
> -	phy-supply = <&vcc5v0_sys>;
> +	phy-supply = <&vcc5v0_host>;
>  	status = "okay";
>  };
>  
> -- 
> 2.50.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler

[Anand Moon]

The fusb302 driver triggers a "BUG: Invalid wait context" lockdep warning
under certain configurations (such as when CONFIG_PROVE_RAW_LOCK_NESTING
is enabled). This occurs because the interrupt handler, fusb302_irq_intn,
attempts to acquire a regular spinlock (&chip->irq_lock) while running
in hardirq context can lead to invalid wait context reports if the lock is
considered "sleepable" or has incompatible nesting levels with the
underlying interrupt controller's locks.

lockdep warnings:

[   38.935276] [      C0] =============================
[   38.935690] [      C0] [ BUG: Invalid wait context ]
[   38.936106] [      C0] 6.19.0-rc2-2-ARM64-GCC #2 Tainted: GT
[   38.936716] [      C0] -----------------------------
[   38.937129] [      C0] kworker/0:0/8 is trying to lock:
[   38.937566] [      C0] ffff000112c04190 (&chip->irq_lock){....}-{3:3}, at: fusb302_irq_intn+0x38/0x98 [fusb302]
[   38.938450] [      C0] other info that might help us debug this:
[   38.938953] [      C0] context-{2:2}
[   38.939247] [      C0] 2 locks held by kworker/0:0/8:
[   38.939670] [      C0]  #0: ffff000100025148 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x224/0x4b8
[   38.940645] [      C0]  #1: ffff8000800fbd90 ((work_completion)(&(&host->detect)->work)){+.+.}-{0:0}, at: process_one_work+0x24c/0x4b8
[   38.941691] [      C0] stack backtrace:
[   38.942010] [      C0] CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Tainted: GT   6.19.0-rc2-2-ARM64-GCC #2 PREEMPT(full)  bd73c5afc1bd41f04ef9699c14f0381f835f4deb
[   38.942017] [      C0] Tainted: [T]=RANDSTRUCT
[   38.942019] [      C0] Hardware name: Radxa ROCK 5B (DT)
[   38.942022] [      C0] Workqueue: events_freezable mmc_rescan
[   38.942031] [      C0] Call trace:
[   38.942033] [      C0]  show_stack+0x24/0x40 (C)
[   38.942041] [      C0]  dump_stack_lvl+0x90/0xd8
[   38.942047] [      C0]  dump_stack+0x1c/0x3c
[   38.942051] [      C0]  __lock_acquire+0x5e8/0x9c8
[   38.942059] [      C0]  lock_acquire+0x134/0x280
[   38.942065] [      C0]  _raw_spin_lock_irqsave+0x80/0xb0
[   38.942072] [      C0]  fusb302_irq_intn+0x38/0x98 [fusb302 634bac905a09c450b54f88b96019accd2820228f]
[   38.942082] [      C0]  __handle_irq_event_percpu+0x138/0x3f0
[   38.942088] [      C0]  handle_irq_event+0x58/0xd8
[   38.942093] [      C0]  handle_level_irq+0x108/0x190
[   38.942099] [      C0]  handle_irq_desc+0x4c/0x78
[   38.942106] [      C0]  generic_handle_domain_irq+0x24/0x40
[   38.942113] [      C0]  rockchip_irq_demux+0x128/0x240
[   38.942120] [      C0]  handle_irq_desc+0x4c/0x78
[   38.942127] [      C0]  generic_handle_domain_irq+0x24/0x40
[   38.942133] [      C0]  __gic_handle_irq_from_irqson.isra.0+0x260/0x370
[   38.942141] [      C0]  gic_handle_irq+0x68/0xa0
[   38.942146] [      C0]  call_on_irq_stack+0x48/0x68
[   38.942152] [      C0]  do_interrupt_handler+0x74/0x98
[   38.942158] [      C0]  el1_interrupt+0x88/0xb0
[   38.942165] [      C0]  el1h_64_irq_handler+0x1c/0x30
[   38.942170] [      C0]  el1h_64_irq+0x84/0x88
[   38.942175] [      C0]  arch_counter_get_cntpct+0x4/0x20 (P)
[   38.942181] [      C0]  __const_udelay+0x30/0x48
[   38.942187] [      C0]  mci_send_cmd.constprop.0+0x84/0xc8
[   38.942194] [      C0]  dw_mci_setup_bus+0x60/0x210
[   38.942200] [      C0]  dw_mci_set_ios+0x1c8/0x260
[   38.942206] [      C0]  mmc_set_initial_state+0x110/0x140
[   38.942211] [      C0]  mmc_rescan_try_freq+0x154/0x198
[   38.942216] [      C0]  mmc_rescan+0x1cc/0x278
[   38.942221] [      C0]  process_one_work+0x284/0x4b8
[   38.942225] [      C0]  worker_thread+0x264/0x3a0
[   38.942230] [      C0]  kthread+0x11c/0x138
[   38.942236] [      C0]  ret_from_fork+0x10/0x20
[   38.969307] [     T11] rockchip-dw-pcie a41000000.pcie: PCI host bridge to bus 0004:40
[   38.969995] [     T11] pci_bus 0004:40: root bus resource [bus 40-4f]

Following changes resolves the lockdep warnings and aligns the driver with best
practices for I2C-based interrupt handling.

Cc: Hans de Goede <hansg@kernel.org>
Cc: Yongbo Zhang <giraffesnn123@gmail.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
 drivers/usb/typec/tcpm/fusb302.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
index 870a71f953f6..089722b52fbb 100644
--- a/drivers/usb/typec/tcpm/fusb302.c
+++ b/drivers/usb/typec/tcpm/fusb302.c
@@ -1755,9 +1755,10 @@ static int fusb302_probe(struct i2c_client *client)
 		goto destroy_workqueue;
 	}
 
-	ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn,
-			  IRQF_ONESHOT | IRQF_TRIGGER_LOW,
-			  "fsc_interrupt_int_n", chip);
+	ret = request_threaded_irq(chip->gpio_int_n_irq,
+				   NULL, fusb302_irq_intn,
+				   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
+				   "fsc_interrupt_int_n", chip);
 	if (ret < 0) {
 		dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret);
 		goto tcpm_unregister_port;
-- 
2.50.1

Re: [PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler

[Hans de Goede]

Hi,

On 3-Jan-26 09:31, Anand Moon wrote:
> The fusb302 driver triggers a "BUG: Invalid wait context" lockdep warning
> under certain configurations (such as when CONFIG_PROVE_RAW_LOCK_NESTING
> is enabled). This occurs because the interrupt handler, fusb302_irq_intn,
> attempts to acquire a regular spinlock (&chip->irq_lock) while running
> in hardirq context can lead to invalid wait context reports if the lock is
> considered "sleepable" or has incompatible nesting levels with the
> underlying interrupt controller's locks.
> 
> lockdep warnings:
> 
> [   38.935276] [      C0] =============================
> [   38.935690] [      C0] [ BUG: Invalid wait context ]
> [   38.936106] [      C0] 6.19.0-rc2-2-ARM64-GCC #2 Tainted: GT
> [   38.936716] [      C0] -----------------------------
> [   38.937129] [      C0] kworker/0:0/8 is trying to lock:
> [   38.937566] [      C0] ffff000112c04190 (&chip->irq_lock){....}-{3:3}, at: fusb302_irq_intn+0x38/0x98 [fusb302]
> [   38.938450] [      C0] other info that might help us debug this:
> [   38.938953] [      C0] context-{2:2}
> [   38.939247] [      C0] 2 locks held by kworker/0:0/8:
> [   38.939670] [      C0]  #0: ffff000100025148 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x224/0x4b8
> [   38.940645] [      C0]  #1: ffff8000800fbd90 ((work_completion)(&(&host->detect)->work)){+.+.}-{0:0}, at: process_one_work+0x24c/0x4b8
> [   38.941691] [      C0] stack backtrace:
> [   38.942010] [      C0] CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Tainted: GT   6.19.0-rc2-2-ARM64-GCC #2 PREEMPT(full)  bd73c5afc1bd41f04ef9699c14f0381f835f4deb
> [   38.942017] [      C0] Tainted: [T]=RANDSTRUCT
> [   38.942019] [      C0] Hardware name: Radxa ROCK 5B (DT)
> [   38.942022] [      C0] Workqueue: events_freezable mmc_rescan
> [   38.942031] [      C0] Call trace:
> [   38.942033] [      C0]  show_stack+0x24/0x40 (C)
> [   38.942041] [      C0]  dump_stack_lvl+0x90/0xd8
> [   38.942047] [      C0]  dump_stack+0x1c/0x3c
> [   38.942051] [      C0]  __lock_acquire+0x5e8/0x9c8
> [   38.942059] [      C0]  lock_acquire+0x134/0x280
> [   38.942065] [      C0]  _raw_spin_lock_irqsave+0x80/0xb0
> [   38.942072] [      C0]  fusb302_irq_intn+0x38/0x98 [fusb302 634bac905a09c450b54f88b96019accd2820228f]
> [   38.942082] [      C0]  __handle_irq_event_percpu+0x138/0x3f0
> [   38.942088] [      C0]  handle_irq_event+0x58/0xd8
> [   38.942093] [      C0]  handle_level_irq+0x108/0x190
> [   38.942099] [      C0]  handle_irq_desc+0x4c/0x78
> [   38.942106] [      C0]  generic_handle_domain_irq+0x24/0x40
> [   38.942113] [      C0]  rockchip_irq_demux+0x128/0x240
> [   38.942120] [      C0]  handle_irq_desc+0x4c/0x78
> [   38.942127] [      C0]  generic_handle_domain_irq+0x24/0x40
> [   38.942133] [      C0]  __gic_handle_irq_from_irqson.isra.0+0x260/0x370
> [   38.942141] [      C0]  gic_handle_irq+0x68/0xa0
> [   38.942146] [      C0]  call_on_irq_stack+0x48/0x68
> [   38.942152] [      C0]  do_interrupt_handler+0x74/0x98
> [   38.942158] [      C0]  el1_interrupt+0x88/0xb0
> [   38.942165] [      C0]  el1h_64_irq_handler+0x1c/0x30
> [   38.942170] [      C0]  el1h_64_irq+0x84/0x88
> [   38.942175] [      C0]  arch_counter_get_cntpct+0x4/0x20 (P)
> [   38.942181] [      C0]  __const_udelay+0x30/0x48
> [   38.942187] [      C0]  mci_send_cmd.constprop.0+0x84/0xc8
> [   38.942194] [      C0]  dw_mci_setup_bus+0x60/0x210
> [   38.942200] [      C0]  dw_mci_set_ios+0x1c8/0x260
> [   38.942206] [      C0]  mmc_set_initial_state+0x110/0x140
> [   38.942211] [      C0]  mmc_rescan_try_freq+0x154/0x198
> [   38.942216] [      C0]  mmc_rescan+0x1cc/0x278
> [   38.942221] [      C0]  process_one_work+0x284/0x4b8
> [   38.942225] [      C0]  worker_thread+0x264/0x3a0
> [   38.942230] [      C0]  kthread+0x11c/0x138
> [   38.942236] [      C0]  ret_from_fork+0x10/0x20
> [   38.969307] [     T11] rockchip-dw-pcie a41000000.pcie: PCI host bridge to bus 0004:40
> [   38.969995] [     T11] pci_bus 0004:40: root bus resource [bus 40-4f]
> 
> Following changes resolves the lockdep warnings and aligns the driver with best
> practices for I2C-based interrupt handling.
> 
> Cc: Hans de Goede <hansg@kernel.org>
> Cc: Yongbo Zhang <giraffesnn123@gmail.com>
> Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
> Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>

If you look closer at the code then you will see that
fusb302_irq_intn() is effectively doing its own threaded
interrupt handling this is done to be able to delay
the threaded part till after the i2c-controller is
resumed when a fusb302 irq wakes up the system.

See commit 207338ec5a27 ("usb: typec: fusb302: Improve
suspend/resume handling") for details.

And if you look at the fusb302 git history then you'll
seen an earlier change the switch the interrupt handler
to a threaded IRQ which was reverted (mostly due to it
also making other undesirable changes).

This change is different though. This is actually quite
similar to commit cee3dba7b741 ("mei: vsc: Fix "BUG: Invalid
wait context" lockdep error"). Where I fixed more or less
the same issue in the same way. So I guess this change also
is ok.

Still ideally we would solve this in another way then
switching to a threaded IRQ handler.

As the commit message of the mei-vsc fix mentions
the root cause of these errors is typically an interrupt
chip driver which uses IRQF_NO_THREAD disabling the auto
threading of all interrupt handlers in RT mode.

So the first question here would be to see if that flag is
used in the interrupt chip and if yes, is that flag really
necessary ?

Regards,

Hans











> ---
>  drivers/usb/typec/tcpm/fusb302.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
> index 870a71f953f6..089722b52fbb 100644
> --- a/drivers/usb/typec/tcpm/fusb302.c
> +++ b/drivers/usb/typec/tcpm/fusb302.c
> @@ -1755,9 +1755,10 @@ static int fusb302_probe(struct i2c_client *client)
>  		goto destroy_workqueue;
>  	}
>  
> -	ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn,
> -			  IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> -			  "fsc_interrupt_int_n", chip);
> +	ret = request_threaded_irq(chip->gpio_int_n_irq,
> +				   NULL, fusb302_irq_intn,
> +				   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> +				   "fsc_interrupt_int_n", chip);
>  	if (ret < 0) {
>  		dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret);
>  		goto tcpm_unregister_port;

Re: [PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler

[张永波]

> Still ideally we would solve this in another way then
> switching to a threaded IRQ handler.
>
> As the commit message of the mei-vsc fix mentions
> the root cause of these errors is typically an interrupt
> chip driver which uses IRQF_NO_THREAD disabling the auto
> threading of all interrupt handlers in RT mode.
>
> So the first question here would be to see if that flag is
> used in the interrupt chip and if yes, is that flag really
> necessary ?
This is very similar to the issue addressed in commit 24b176d8827d
("drm/msm/dsi: Remove spurious IRQF_ONESHOT flag").
The IRQF_ONESHOT flag is preventing forced threading here.

In irq_setup_forced_threading(), the conversion to threaded interrupts
is explicitly skipped if any of the IRQF_NO_THREAD, IRQF_PERCPU,
or IRQF_ONESHOT flags are present. In this case, IRQF_ONESHOT
appears to be the reason.

Regards,
giraffesnn

Re: [PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler

[Hans de Goede]

Hi,

On 7-Jan-26 10:52, 张永波 wrote:
>> Still ideally we would solve this in another way then
>> switching to a threaded IRQ handler.
>>
>> As the commit message of the mei-vsc fix mentions
>> the root cause of these errors is typically an interrupt
>> chip driver which uses IRQF_NO_THREAD disabling the auto
>> threading of all interrupt handlers in RT mode.
>>
>> So the first question here would be to see if that flag is
>> used in the interrupt chip and if yes, is that flag really
>> necessary ?
> This is very similar to the issue addressed in commit 24b176d8827d
> ("drm/msm/dsi: Remove spurious IRQF_ONESHOT flag").
> The IRQF_ONESHOT flag is preventing forced threading here.
> 
> In irq_setup_forced_threading(), the conversion to threaded interrupts
> is explicitly skipped if any of the IRQF_NO_THREAD, IRQF_PERCPU,
> or IRQF_ONESHOT flags are present. In this case, IRQF_ONESHOT
> appears to be the reason.

Ah, well the code effectively does its own IRQF_ONESHOT handling,
since it needs to do its own threaded-irq like handling for
suspend/resume reasons. It disables the IRQ when it fires and
then only re-enables it once the work has done processing the IRQ.

So it should be perfectly safe to drop the IRQF_ONESHOT flag.

If that also works to resolve the lockdep issue that would be
the preferred way of fixing this IMHO.

Regards,

Hans

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]

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
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]