On Fri 20 Jan 08:13 PST 2017, Julia Cartwright wrote: > The MSM pinctrl driver currently implements an irq_chip for handling > GPIO interrupts; due to how irq_chip handling is done, it's necessary > for the irq_chip methods to be invoked from hardirq context, even on a > a real-time kernel. Because the spinlock_t type becomes a "sleeping" > spinlock w/ RT kernels, it is not suitable to be used with irq_chips. > Thanks for the explanation. > A quick audit of the operations under the lock reveal that they do only > minimal, bounded work, and are therefore safe to do under a raw > spinlock. > I agree with this conclusion. > On real-time kernels, this fixes an OOPs which looks like the following, > as reported by Brian Wrenn: > > kernel BUG at kernel/locking/rtmutex.c:1014! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in: spidev_irq(O) smsc75xx wcn36xx [last unloaded: spidev] > CPU: 0 PID: 1163 Comm: irq/144-mmc0 Tainted: G W O 4.4.9-linaro-lt-qcom #1 > PC is at rt_spin_lock_slowlock+0x80/0x2d8 > LR is at rt_spin_lock_slowlock+0x68/0x2d8 > [..] > Call trace: > rt_spin_lock_slowlock > rt_spin_lock > msm_gpio_irq_ack > handle_edge_irq > generic_handle_irq > msm_gpio_irq_handler > generic_handle_irq > __handle_domain_irq > gic_handle_irq > > Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> Acked-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
