[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260103083232.9510-4-linux.amoon@gmail.com>
Date: Sat, 3 Jan 2026 14:01:19 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Heiko Stuebner <heiko@...ech.de>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sebastian Reichel <sebastian.reichel@...labora.com>,
FUKAUMI Naoki <naoki@...xa.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
Yongbo Zhang <giraffesnn123@...il.com>,
devicetree@...r.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS),
linux-arm-kernel@...ts.infradead.org (moderated list:ARM/Rockchip SoC support),
linux-rockchip@...ts.infradead.org (open list:ARM/Rockchip SoC support),
linux-kernel@...r.kernel.org (open list),
linux-usb@...r.kernel.org (open list:USB TYPEC CLASS)
Cc: Anand Moon <linux.amoon@...il.com>,
Hans de Goede <hansg@...nel.org>
Subject: [PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler
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@...nel.org>
Cc: Yongbo Zhang <giraffesnn123@...il.com>
Cc: Sebastian Reichel <sebastian.reichel@...labora.com>
Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
Signed-off-by: Anand Moon <linux.amoon@...il.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
Powered by blists - more mailing lists