| Message ID | 1345540555-24359-3-git-send-email-balbi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 21 Aug 2012 12:15:44 +0300 Felipe Balbi <balbi@ti.com> wrote: > Even if we enter our IRQ handler just to notice > that the our device didn't generate the IRQ, > that still means "handling" and IRQ, so let's > return IRQ_HANDLED. That looks wrong - you'll defeat the stuck IRQ protection. If we didn't cause the IRQ then we are IRQ_NONE ?
On Tue, Aug 21, 2012 at 12:50:05PM +0100, Alan Cox wrote: > On Tue, 21 Aug 2012 12:15:44 +0300 > Felipe Balbi <balbi@ti.com> wrote: > > > Even if we enter our IRQ handler just to notice > > that the our device didn't generate the IRQ, > > that still means "handling" and IRQ, so let's > > return IRQ_HANDLED. > > That looks wrong - you'll defeat the stuck IRQ protection. If we didn't > cause the IRQ then we are IRQ_NONE ? that's true. I'll drop this patch from the list. My bad.
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 5c0d0bc..b4b95fc 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -417,7 +417,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void *dev_id) if (iir & UART_IIR_NO_INT) { pm_runtime_mark_last_busy(&up->pdev->dev); pm_runtime_put_autosuspend(&up->pdev->dev); - return IRQ_NONE; + return IRQ_HANDLED; } spin_lock_irqsave(&up->port.lock, flags);
Even if we enter our IRQ handler just to notice that the our device didn't generate the IRQ, that still means "handling" and IRQ, so let's return IRQ_HANDLED. Signed-off-by: Felipe Balbi <balbi@ti.com> --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)