[PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler

[Mukesh Ojha]

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
>