On Thu, Jun 14, 2012 at 4:53 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Thu, Jun 14, 2012 at 04:48:56PM +0530, Shilimkar, Santosh wrote: >> On Thu, Jun 14, 2012 at 3:50 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > otherwise we could get our IRQ line disabled due >> > to many spurious IRQs. >> > >> > Signed-off-by: Felipe Balbi <balbi@xxxxxx> >> > --- >> > drivers/i2c/busses/i2c-omap.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c >> > index fc5b8bc..5b78a73 100644 >> > --- a/drivers/i2c/busses/i2c-omap.c >> > +++ b/drivers/i2c/busses/i2c-omap.c >> > @@ -1015,7 +1015,7 @@ omap_i2c_isr(int this_irq, void *dev_id) >> > } >> > } while (stat); >> > >> > - return count ? IRQ_HANDLED : IRQ_NONE; >> > + return IRQ_HANDLED; >> >> no sure if this is correct. if you have IRQ flood and instead of _actually_ >> handling it, if you return handled, you still have interrupt pending, right? > > The point of returning IRQ_NONE is to indicate to the interrupt layer that > the interrupt you received was not processed by any interrupt handler, and > therefore to provide a way of preventing the system being brought to a halt > though a stuck interrupt line. > > So, if you do process an interrupt, you should always return IRQ_HANDLED > even if you couldn't complete its processing (eg, because you've serviced > it 100 times.) That make sense. Thanks for explanation Russell. Regards santosh -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
