From: Vojtech Pavlik <vojtech@suse.cz>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "Fernando Luis Vázquez Cao" <fernando@oss.ntt.co.jp>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH] fix return value of i8042_aux_test_irq
Date: Thu, 26 Jul 2007 16:38:04 +0200 [thread overview]
Message-ID: <20070726143804.GB31507@suse.cz> (raw)
In-Reply-To: <d120d5000707260654l74d61359v4f17790ab06ac0a3@mail.gmail.com>
On Thu, Jul 26, 2007 at 09:54:50AM -0400, Dmitry Torokhov wrote:
> Hi,
>
> On 7/26/07, Fernando Luis Vázquez Cao <fernando@oss.ntt.co.jp> wrote:
> >I made an interesting finding while testing the two patches below.
> >
> >http://lkml.org/lkml/2007/7/19/685
> >http://lkml.org/lkml/2007/7/19/687
> >
> >These patches modify the traditional CONFIG_DEBUG_KERNEL in such a way
> >that the request_irq prints a warning if after calling the handler it
> >returned IRQ_HANDLED .
> >
> >The code looks like this:
> >
> >int request_irq(unsigned int irq, irq_handler_t handler,
> > unsigned long irqflags, const char *devname, void
> >*dev_id)
> >.....
> > if (irqflags & IRQF_DISABLED) {
> > unsigned long flags;
> >
> > local_irq_save(flags);
> > retval = handler(irq, dev_id);
> > local_irq_restore(flags);
> > } else
> > retval = handler(irq, dev_id);
> > if (retval == IRQ_HANDLED) {
> > printk(KERN_WARNING
> > "%s (IRQ %d) handled a spurious interrupt\n",
> > devname, irq);
> > }
> >.....
> >
> >I discovered that i8042_aux_test_irq handles the "fake" interrupt,
> >which, in principle, is not correct because it obviously isn't a real
> >interrupt and it could have been a spurious interrupt as well.
> >
> >The problem is that the interrupt handler unconditionally returns IRQ
> >handled, which does not seem correct. Anyway I am not very familiar with
> >this code so I may be missing the whole point. I would appreciate your
> >comments on this.
> >
>
> The handler does handle the interrupt - both status and data registers
> are read so from the keyboard controller point of view the interrupt
> has been handled even if we happen to discard the data. As far as I
> know IRQ12 is never shared by BIOS... Vojtech, do you remember why we
> request IRQ12 with IRQF_SHARED?
I believe it was needed on PPC.
--
Vojtech Pavlik
Director SuSE Labs
next prev parent reply other threads:[~2007-07-26 14:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 8:04 Fernando Luis Vázquez Cao
2007-07-26 13:54 ` Dmitry Torokhov
2007-07-26 14:10 ` Alan Cox
2007-07-26 14:49 ` fernando
2007-07-26 15:29 ` Alan Cox
2007-07-26 15:57 ` fernando
2007-07-29 5:27 ` Dmitry Torokhov
2007-07-26 14:38 ` Vojtech Pavlik [this message]
2007-07-26 14:39 ` fernando
2007-07-26 15:51 ` fernando
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=20070726143804.GB31507@suse.cz \
--to=vojtech@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=fernando@oss.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®