Hi Mukesh, > The return value of an interrupt handler is the special type > irqreturn_t. An interrupt handler can return two special values, > IRQ_NONE or IRQ_HANDLED.
Yep, you can assume that the reader knows that level of the interrupt handler API :) What we want to know is how that change in behaviour of the handler code interacts with the core irq handler code. The change you're proposing always returns IRQ_HANDLED, whereas the previous code had cases where it returned: - IRQ_NONE, or - the (invalid) value -1. Unless I'm mistaken, there are two things I can see happening with the old code: if we hit the IRQ_NONE path enough, we'll report a "nobody cared" error (see __report_bad_irq) and disable the interrupt, or for the -1 case, we'll immediately log a "bogus return value" error (and, it looks like a "no thread function available" error too, from warn_no_thread). So, it would be nice to mention that this change will fix errors that result in those log messages. This means that someone debugging those log messages in futures can find your patch, and see that it addresses the issue. > No, this is not user visible issue.. I consider the kernel log output to be user-visible. > and also here it does not matter what we return from here as we > are not handling the return value of the handler. *We* are not handling the return value of the handler, but the core IRQ code is. Regards, Jeremy