On Thu, 30 Sep 2021 14:36:52 +0100,
Daniel Palmer <daniel@xxxxxxxx> wrote:
>
> Hi Marc,
>
> On Thu, 30 Sept 2021 at 22:06, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> > 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.
