On Thu, 30 Sep 2021 14:36:52 +0100,
Daniel Palmer [off-list ref] wrote:

Hi Marc,

On Thu, 30 Sept 2021 at 22:06, Marc Zyngier [off-list ref] wrote:

quoted

No, this is the right spot if you really need to set the handler. But
it should really be after the parent allocation (see below for
something totally untested).

Your change resolves the null pointer difference when enabling the
interrupt but when it triggers the below happens.
This might just be my driver so I'll try to debug.

Thanks,

Daniel

# gpiomon -r 0 44
[   61.770519] irq 66, desc: (ptrval), depth: 0, count: 0, unhandled: 0
[   61.770646]
[   61.770659] =============================
[   61.770670] [ BUG: Invalid wait context ]
[   61.770683] 5.15.0-rc2+ #2583 Not tainted
[   61.770702] -----------------------------
[   61.770712] swapper/0/0 is trying to lock:
[   61.770729] c1789eb0 (&port_lock_key){-.-.}-{3:3}, at:
serial8250_console_write+0x1b0/0x254
[   61.770840] other info that might help us debug this:
[   61.770853] context-{2:2}
[   61.770868] 2 locks held by swapper/0/0:
[   61.770889]  #0: c10189ec (console_lock){+.+.}-{0:0}, at:
vprintk_emit+0xa4/0x200
[   61.770986]  #1: c1018b44 (console_owner){-...}-{0:0}, at:
console_unlock+0x1e8/0x4b4
[   61.771080] stack backtrace:
[   61.771093] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-rc2+ #2583
[   61.771130] Hardware name: MStar/Sigmastar Armv7 (Device Tree)
[   61.771156] [<c010daf0>] (unwind_backtrace) from [<c0109f54>]
(show_stack+0x10/0x14)
[   61.771235] [<c0109f54>] (show_stack) from [<c09303a0>]
(dump_stack_lvl+0x58/0x70)
[   61.771312] [<c09303a0>] (dump_stack_lvl) from [<c016fbd8>]
(__lock_acquire+0x384/0x16a0)
[   61.771394] [<c016fbd8>] (__lock_acquire) from [<c017191c>]
(lock_acquire+0x2a0/0x320)
[   61.771470] [<c017191c>] (lock_acquire) from [<c093de84>]
(_raw_spin_lock_irqsave+0x5c/0x70)
[   61.771542] [<c093de84>] (_raw_spin_lock_irqsave) from [<c04cdf98>]
(serial8250_console_write+0x1b0/0x254)
[   61.771620] [<c04cdf98>] (serial8250_console_write) from
[<c0178068>] (console_unlock+0x3fc/0x4b4)
[   61.771699] [<c0178068>] (console_unlock) from [<c0179750>]
(vprintk_emit+0x1d0/0x200)
[   61.771769] [<c0179750>] (vprintk_emit) from [<c017979c>]
(vprintk_default+0x1c/0x24)
[   61.771840] [<c017979c>] (vprintk_default) from [<c092d178>]
(_printk+0x18/0x28)
[   61.771914] [<c092d178>] (_printk) from [<c017b9d0>]
(handle_bad_irq+0x44/0x22c)
[   61.771991] [<c017b9d0>] (handle_bad_irq) from [<c017ade4>]
(handle_irq_desc+0x24/0x34)
[   61.772066] [<c017ade4>] (handle_irq_desc) from [<c0467274>]
(ssd20xd_gpi_chainedhandler+0xb4/0xc4)
[   61.772147] [<c0467274>] (ssd20xd_gpi_chainedhandler) from
[<c017ade4>] (handle_irq_desc+0x24/0x34)
[   61.772223] [<c017ade4>] (handle_irq_desc) from [<c017b544>]
(handle_domain_irq+0x40/0x54)
[   61.772299] [<c017b544>] (handle_domain_irq) from [<c0465f20>]
(gic_handle_irq+0x60/0x6c)
[   61.772372] [<c0465f20>] (gic_handle_irq) from [<c0100aac>]
(__irq_svc+0x4c/0x64)

Somehow, the handler for this interrupt is set to handle_bad_irq(),
which probably isn't what you want. You'll have to find out who sets
this (there is a comment about that in gpiolib.c, but I haven't had a
chance to find where this is coming from).

Do you happen to set it in your driver?

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel