Re: BUG: "scheduling while atomic" with MCP23008 + matrix_keypad IRQ mode on Linux 6.15.5

[Alexander Stein <alexander.stein@ew.tq-group.com>]

Am Donnerstag, 10. Juli 2025, 13:44:01 CEST schrieb Lukas Schmid:
> Hi all,
> 
> I'm encountering a "BUG: scheduling while atomic" when using the MCP23008 GPIO 
> expander with the `matrix_keypad` driver in IRQ mode on Linux v6.15.5
> 
> Hardware setup:
> - MCP23008 connected via I2C
> - 4x4 matrix keypad hooked to MCP23008 GPIOs
> - SoC: Allwinner T113-s3 SoC
> - Using devicetree configuration for `microchip,mcp23008` and `gpio-
> matrix-keypad`
> 
> When I press buttons on the keypad, after some amount of presses I get the 
> following error from the Kernel:
> 
> [   81.921114] BUG: scheduling while atomic: kworker/1:4/383/0x00000002
> [   81.921155] Modules linked in: esp32_sdio(O) bluetooth ecdh_generic ecc 
> cfg80211 rfkill ipv6 af_packet evdev matrix_keypad matrix_keymap 
> pinctrl_mcp23s08_i2c pinctrl_mcp23s08 sun8i_ce crypto_engine uio_pdrv_genirq 
> uio
> [   81.921287] CPU: 1 UID: 0 PID: 383 Comm: kworker/1:4 Tainted: G           O        
> 6.15.4 #1 PREEMPT 
> [   81.921305] Tainted: [O]=OOT_MODULE
> [   81.921310] Hardware name: Generic DT based system
> [   81.921317] Workqueue: events matrix_keypad_scan [matrix_keypad]
> [   81.921343] Call trace: 
> [   81.921353]  unwind_backtrace from show_stack+0x18/0x1c
> [   81.921381]  show_stack from dump_stack_lvl+0x68/0x74
> [   81.921398]  dump_stack_lvl from __schedule_bug+0x5c/0x70
> [   81.921423]  __schedule_bug from __schedule+0xb48/0xd24
> [   81.921451]  __schedule from schedule+0x34/0x144
> [   81.921472]  schedule from schedule_preempt_disabled+0x24/0x34
> [   81.921494]  schedule_preempt_disabled from __mutex_lock.constprop.
> 0+0x308/0xaa4
> [   81.921519]  __mutex_lock.constprop.0 from mcp23s08_irq_bus_lock+0x20/0x30 
> [pinctrl_mcp23s08]
> [   81.921553]  mcp23s08_irq_bus_lock [pinctrl_mcp23s08] from 
> __irq_get_desc_lock+0x84/0xac
> [   81.921584]  __irq_get_desc_lock from enable_irq+0x38/0xa8
> [   81.921605]  enable_irq from matrix_keypad_scan+0x2b8/0x3ac [matrix_keypad]
> [   81.921626]  matrix_keypad_scan [matrix_keypad] from 
> process_one_work+0x160/0x410
> [   81.921649]  process_one_work from worker_thread+0x25c/0x408
> [   81.921668]  worker_thread from kthread+0x144/0x264
> [   81.921685]  kthread from ret_from_fork+0x14/0x38
> [   81.921699] Exception stack(0xc896dfb0 to 0xc896dff8)
> [   81.921709] dfa0:                                     00000000 00000000 
> 00000000 00000000
> [   81.921720] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 
> 00000000 00000000
> [   81.921730] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> 
> Happy to test patches or provide further debugging info.

The culprit is
> scoped_guard(spinlock_irq, &keypad->lock) {
> 	keypad->scan_pending = false;
> 	enable_row_irqs(keypad);
> }

Here a spinlock is held, while during enable_irq() call the function
mcp23s08_irq_bus_lock() is called. The latter one tries to lock a mutex
while holding a spinlock. This doesn'twork.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/