On Thursday 16 February 2017 08:10 AM, Jeremy Kerr wrote:
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 :)
Sorry i misunderstood your question.
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.
Agree.
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).
bogus return value" error will not come as
action_ret <= (IRQ_HANDLED | IRQ_WAKE_THREAD)
i.e
0/-1 <= 3 (true)
and also "no thread function available" as
we are not returning IRQ_WAKE_THREAD from handler.
Changing the patch description in v2.
Regards,
Mukesh
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
