On Wed, Mar 14, 2018 at 04:17:33PM +0000, Ben Hutchings wrote: > On Tue, 2018-03-13 at 11:09 -0700, Dmitry Torokhov wrote: > > On Mon, Mar 12, 2018 at 10:51:48PM +0000, Ben Hutchings wrote: > > > matrix_keypad_stop() now serialises with matrix_keypad_interrupt() > > > using spin_lock_irq() while setting the "stopped" flag, but it drops > > > the lock before disabling the interrupt sources. If an interrupt is > > > asserted at this point, matrix_keypad_interrupt() will ignore it > > > because stopped is true. The interrupt will remain asserted and it > > > may be called repeatedly, potentially leading to a hard lockup on a UP > > > system. > > > > No, it will not. We acknowledge interrupt (return IRQ_HANDLED) even when > > keypad is stopped, and because we are dealing with a bunch of GPIOs (and > > not some controller that has internal state and would not deassert the > > attention line until we read or otherwise clear the state) the > > interrupts will not be re-assered (unless there is a keypress, but even > > then we'll simply re-acknowledge interrupt again). > [...] > > Returning IRQ_HANDLED has no effect on the hardware; it's mostly used > for spurious interrupt detection. Yes. You still need to acknowledge that interrupt was handled. I.e. if the keypad driver was returning 0 (IRQ_NONE) while it is "stopped", that would be wrong and the system could consider interrupt spurious one. > But I think what you're saying that > these interrupts will always be edge-triggered, not level-triggered - > is that right? In which case I agree that screaming interrupts won't > be a problem. Yes, level-triggered interrupts are not usable whenever something is based on GPIOs as while that "something" is active you'd have interrupt constantly retriggered as soon as you done processing it. We explicitly request interrupts as IRQG_TRIGGER_FALLING | IRQF_TRIGGER_RISING in matrix-keypad driver. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
