[PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler
mukesh02 at linux.vnet.ibm.com
Tue Feb 21 00:19:42 AEDT 2017
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.
> 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
bogus return value" error will not come as
action_ret <= (IRQ_HANDLED | IRQ_WAKE_THREAD)
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.
> 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.
More information about the Linuxppc-dev