From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: "Jeff Garzik" <jgarzik@pobox.com>,
"long" <tlnguyen@snoqualmie.dp.intel.com>
Cc: <linux-kernel@vger.kernel.org>, <greg@kroah.com>,
"Nguyen, Tom L" <tom.l.nguyen@intel.com>, <zwane@linuxpower.ca>
Subject: RE: MSI fix for buggy PCI/PCI-X hardware
Date: Tue, 9 Sep 2003 15:14:19 -0700 [thread overview]
Message-ID: <7F740D512C7C1046AB53446D3720017304AF29@scsmsx402.sc.intel.com> (raw)
Jeff, Hi.
How about the default behavior? I'm not a fan of disable_msi(), because
we need to update the driver as we find problems, and we cannot predict
which PCI/PCI-X devices in the world have such a problem, although we
know some will. The workaround in drivers/pci/quirk.c is much better,
compared to modifying the driver, but we still need to update the file
(and rebuild the kernel) as we find problems.
In my opinion, we might want to use drivers/pci/quirk.c to blacklist PCI
Express devices if any (hope not). For PCI/PCI-X devices, we might want
to enable MSI once verified for it. To that end we can also use
drivers/pci/quirk.c to whitelist them (or it's abuse?). That way we can
avoid situations like "it hangs, it does not get interrupts", "disable
ACPI, oh no, MSI".
Thanks,
Jun
> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Tuesday, September 09, 2003 11:41 AM
> To: long
> Cc: linux-kernel@vger.kernel.org; greg@kroah.com; Nakajima, Jun;
Nguyen,
> Tom L; zwane@linuxpower.ca
> Subject: Re: MSI fix for buggy PCI/PCI-X hardware
>
> On Tue, Sep 09, 2003 at 08:39:37AM -0700, long wrote:
> > The proposed solution is to provide a new API, named "int
> > disable_msi(struct pci_dev *dev)", to allow IHV's who have
> > shipped PCI/PCI-X hardware that does not work in MSI mode to update
> > their software drivers to request the kernel to switch the
> > interrupt mode from MSI mode back to IRQ pin-assertion mode.
>
> No need for a new API. We have drivers/pci/quirk.c where we add PCI
> devices with known bugs. If there is commonality of the bugs across
> hardware, we can easily add a common "quirk" which fixes the
situation.
>
> Individual drivers shouldn't need to bother with this, really.
>
> As an aside, if you need to blacklist certain _systems_ rather than
> certain PCI devices, you should either modify drivers/pci/quirks.c or
> arch/i386/kernel/dmi_scan.c.
>
> Jeff
>
>
next reply other threads:[~2003-09-09 22:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-09 22:14 Nakajima, Jun [this message]
2003-09-09 22:52 ` MSI fix for buggy PCI/PCI-X hardware Jeff Garzik
2003-09-10 21:31 ` Zwane Mwaikambo
-- strict thread matches above, loose matches on Subject: below --
2003-09-10 1:26 Nakajima, Jun
2003-09-09 15:39 long
2003-09-09 18:41 ` Jeff Garzik
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=7F740D512C7C1046AB53446D3720017304AF29@scsmsx402.sc.intel.com \
--to=jun.nakajima@intel.com \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tlnguyen@snoqualmie.dp.intel.com \
--cc=tom.l.nguyen@intel.com \
--cc=zwane@linuxpower.ca \
/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).