Hi Hans De,

Thanks for your review comments.

On Sat, 3 Jan 2026 at 17:32, Hans de Goede [off-list ref] wrote:

Hi,

On 3-Jan-26 09:31, Anand Moon wrote:

quoted

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 <redacted>
Cc: Sebastian Reichel <redacted>
Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
Signed-off-by: Anand Moon <redacted>

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).

Yes, I have gone through the change logs

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.

Yes, ideally, all the CPU cores should handle the IRQ.

alarm@rockpi-5b:~$ cat  /proc/interrupts | grep fsc_interrupt_int_n
 59:         15          0          0          0          0          0
         0          0 rockchip_gpio_irq  12 Level
fsc_interrupt_int_n

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

I don't know but this could be related to

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 ?

No, I did not find this IRQF_NO_THREAD flag being used by Rockchip SoC
i2c
[1] https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-rk3x.c#L1310-L1325
gpio
[2] https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-rockchip.c#L520-L582
pinctrl
[3] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/pinctrl-rockchip.c
pinctrl power management IC
[4] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/pinctrl-rk805.c

Regards,

Hans

Thnaks
-Anand