From: ebiederm@xmission.com (Eric W. Biederman)
To: Grant Grundler <grundler@parisc-linux.org>
Cc: Greg KH <greg@kroah.com>,
Mitch Williams <mitch.a.williams@intel.com>,
Michael Ellerman <michael@ellerman.id.au>,
linux-pci@atrey.karlin.mff.cuni.cz, gregkh@suse.de,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
auke-jan.h.kok@intel.com
Subject: Re: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table
Date: Tue, 27 Mar 2007 09:15:03 -0600 [thread overview]
Message-ID: <m1mz1yyayw.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070327145552.GB7157@colo.lackof.org> (Grant Grundler's message of "Tue, 27 Mar 2007 08:55:52 -0600")
Grant Grundler <grundler@parisc-linux.org> writes:
> On Tue, Mar 27, 2007 at 07:23:16AM -0600, Eric W. Biederman wrote:
>> I guess I should add that I'm not certain that the code is exactly correct
>> there are weird differences between enable/disable and mask.
>
> My understanding was "enable" would clear (or ignore) pending interrupts
> and "unmask" would deliver pending interrupts. Disable and mask could
> in many implementations be the same thing as long as the enable/unmask
> difference was supported.
enable/disable are what are available to drivers. When the call
enable_irq or disable_irq. Frequently we have code to make up
for deficiencies in the hardware irq controller implementations
here.
mask/unmask are helper functions only used by the internals of the
irq implementation, and actually are required to touch the hardware.
The problem on x86 is that an ioapic will drop interrupts that come
in while it is masked. Thus we have to play software games not
to loose pending interrupts (i.e. leave the irq enabled until we
get a pending interrupt).
So I think you had the general drift although you had a couple of
details confused.
Eric
next prev parent reply other threads:[~2007-03-27 15:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 23:18 Mitch Williams
2007-03-27 0:09 ` Greg KH
2007-03-27 2:26 ` Eric W. Biederman
2007-03-27 13:23 ` Eric W. Biederman
2007-03-27 14:55 ` Grant Grundler
2007-03-27 15:15 ` Eric W. Biederman [this message]
2007-03-27 15:25 ` Grant Grundler
2007-03-27 15:31 ` Williams, Mitch A
2007-03-27 16:01 ` Eric W. Biederman
2007-03-27 17:15 ` Williams, Mitch A
2007-03-27 21:13 ` Eric W. Biederman
2007-03-27 21:43 ` Williams, Mitch A
2007-03-28 1:14 ` Eric W. Biederman
2007-03-28 15:37 ` Williams, Mitch A
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=m1mz1yyayw.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=auke-jan.h.kok@intel.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=grundler@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=michael@ellerman.id.au \
--cc=mitch.a.williams@intel.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
all inboxes | Powered by JetHome®