From: Jeff Garzik <jgarzik@pobox.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: torvalds@osdl.org
Subject: Re: Fix IDE initialization when we don't probe for interrupts.
Date: Wed, 09 Jul 2003 18:08:17 -0400 [thread overview]
Message-ID: <3F0C9251.2010107@pobox.com> (raw)
In-Reply-To: <200307092110.h69LAlgG027527@hera.kernel.org>
Linux Kernel Mailing List wrote:
> ChangeSet 1.1374, 2003/07/09 13:40:53-07:00, torvalds@home.osdl.org
>
> Fix IDE initialization when we don't probe for interrupts.
>
> The driver obviously cannot rely on the interrupt handler
> when it is probing for interrupts, so the identify code is
> written to not use interrupts and the probing code will
> disable the interrupt after having figured out which one it
> is.
>
> The non-probe code should do the same, otherwise confusion
> happens.
> diff -Nru a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
> --- a/drivers/ide/ide-probe.c Wed Jul 9 14:10:54 2003
> +++ b/drivers/ide/ide-probe.c Wed Jul 9 14:10:54 2003
> @@ -390,6 +390,14 @@
> cookie = probe_irq_on();
> /* enable device irq */
> hwif->OUTB(drive->ctl, IDE_CONTROL_REG);
> + } else {
> + /*
> + * Disable device irq if we don't need to
> + * probe for it. Otherwise we'll get spurious
> + * interrupts during the identify-phase that
> + * the irq handler isn't expecting.
> + */
> + hwif->OUTB(drive->ctl|2, IDE_CONTROL_REG);
Yeah, my driver does probing with interrupts disabled, too.
I'm curious where interrupts are re-enabled, though?
Jeff
next parent reply other threads:[~2003-07-09 21:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200307092110.h69LAlgG027527@hera.kernel.org>
2003-07-09 22:08 ` Jeff Garzik [this message]
2003-07-09 22:25 ` Fix IDE initialization when we don't probe for interrupts Linus Torvalds
2003-07-09 22:51 ` Bartlomiej Zolnierkiewicz
2003-07-09 22:52 ` Jeff Garzik
2003-07-17 15:36 ` Geert Uytterhoeven
2003-07-09 23:28 ` Alan Cox
2003-07-17 15:32 ` Geert Uytterhoeven
2003-07-17 15:58 John Bradford
2003-07-17 15:52 ` Geert Uytterhoeven
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=3F0C9251.2010107@pobox.com \
--to=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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;
as well as URLs for NNTP newsgroup(s).