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.1Hi,
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;
Hi Hans De,
Thanks for your review comments.
On Sat, 3 Jan 2026 at 17:32, Hans de Goede <hansg@kernel.org> wrote:
>
> 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).
>
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
> 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
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
Hi Hans,
On Wed, 7 Jan 2026 at 16:22, Hans de Goede <hansg@kernel.org> wrote:
>
> 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.
>
Yes, the warning disappears
> If that also works to resolve the lockdep issue that would be
> the preferred way of fixing this IMHO.
>
After applying these changes, the device initially triggered a hard reset;
And the board reboots. I need to find another way to fix this warning.
However, after several reboots, it returned to a normal boot sequence.
[ 40.404525][ T5974] rockchip-dw-pcie a41000000.pcie: LTSSM_STATUS: 0x130011
[ 40.404936][ T4957] r8169 0004:41:00.0: enabling Mem-Wr-Inval
[ 40.406591][ T56] dwmmc_rockchip fe2d0000.mmc: IDMAC supports
32-bit address mode.
[ 40.407370][ T56] dwmmc_rockchip fe2d0000.mmc: Using internal DMA
controller.
[ 40.408013][ T56] dwmmc_rockchip fe2d0000.mmc: Version ID is 270a
[ 40.408610][ T56] dwmmc_rockchip fe2d0000.mmc: DW MMC controller
at irq 104,32 bit host data width,256 deep fifo
[ 40.413373][ T56] mmc_host mmc2: card is non-removable.
[ 40.431072][ T56] mmc_host mmc2: Bus speed (slot 0) = 400000Hz
(slot req 400000Hz, actual 400000HZ div = 0)
[ 40.468235][ T67] mmc_host mmc2: Bus speed (slot 0) = 300000Hz
(slot req 300000Hz, actual 300000HZ div = 0)
[ 40.492229][ T4957] r8169 0004:41:00.0 eth0: RTL8125B,
00:e0:4c:68:00:35, XID 641, IRQ 153
[ 40.492993][ T4957] r8169 0004:41:00.0 eth0: jumbo features
[frames: 16362 bytes, tx checksumming: ko]
[ 40.493873][ T4957] r8169 0004:41:00.0: vgaarb: pci_notify
[ 40.507133][ T5974] rockchip-dw-pcie a41000000.pcie: Received Link
up event. Starting enumeration!
[ 40.508219][ T5974] pci_bus 0004:40: scanning bus
[ 40.517387][ T5974] pcieport 0004:40:00.0: scanning [bus 41-41]
behind bridge, pass 0
[ 40.517867][ T67] mmc_host mmc2: Bus speed (slot 0) = 200000Hz
(slot req 200000Hz, actual 200000HZ div = 0)
[ 40.518336][ T5974] pci_bus 0004:41: scanning bus
[ 40.519531][ T5974] pci_bus 0004:41: bus scan returning with max=41
[ 40.520294][ T5974] pcieport 0004:40:00.0: scanning [bus 41-41]
behind bridge, pass 1
[ 40.521273][ T5974] pci_bus 0004:40: bus scan returning with max=41
DDR ff1a08bde6 typ 25/03/13-15:39:39,fwver: v1.19
ch0 ttot10
ch1 ttot10
ch2 ttot10
ch3 ttot10
ch0 ttot16
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
ch1 ttot16
channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
ch2 ttot16
channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
ch3 ttot16
channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
Manufacturer ID:0x6
> Regards,
>
> Hans
>
Thanks
-Anand
Hi,
On 8-Jan-26 07:58, Anand Moon wrote:
> Hi Hans,
>
> On Wed, 7 Jan 2026 at 16:22, Hans de Goede <hansg@kernel.org> wrote:
>>
>> 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.
>>
> Yes, the warning disappears
>> If that also works to resolve the lockdep issue that would be
>> the preferred way of fixing this IMHO.
>>
> After applying these changes, the device initially triggered a hard reset;
> And the board reboots. I need to find another way to fix this warning.
Hmm, I guess that without the oneshot flag fusb302_irq_intn() might
trigger a second time before it disables the IRQ causing an IRQ enable
unbalance issue.
So lets just go with your original fix of moving this to a threaded
IRQ handler.
Regards,
Hans
© 2016 - 2026 Red Hat, Inc.