From: Jeremy Kerr <jk@ozlabs.org>
To: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler
Date: Thu, 16 Feb 2017 10:40:00 +0800 [thread overview]
Message-ID: <7bac2667-9b7f-9f05-c444-79b1fad31a6a@ozlabs.org> (raw)
In-Reply-To: <62c1a1c3-3a9e-2a9b-b7c1-c23d8d6efcb6@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2017-02-16 2:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 9:08 [PATCH 1/2] powerpc/powernv/opal-dump : Handles opal_dump_info properly Mukesh Ojha
2016-12-01 9:08 ` [PATCH 2/2] powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler Mukesh Ojha
2017-02-15 3:18 ` Jeremy Kerr
2017-02-15 10:27 ` Mukesh Ojha
2017-02-16 2:40 ` Jeremy Kerr [this message]
2017-02-20 13:19 ` Mukesh Ojha
2017-02-27 0:16 ` Jeremy Kerr
2017-02-15 5:08 ` Stewart Smith
2017-02-15 6:18 ` Mukesh Ojha
2016-12-06 6:37 ` [PATCH 1/2] powerpc/powernv/opal-dump : Handles opal_dump_info properly Mukesh Ojha
2017-02-13 6:32 ` Mukesh Ojha
2017-02-15 3:18 ` Jeremy Kerr
2017-02-15 5:04 ` Stewart Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7bac2667-9b7f-9f05-c444-79b1fad31a6a@ozlabs.org \
--to=jk@ozlabs.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mukesh02@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).