public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brice Goglin <brice@myri.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-pci@atrey.karlin.mff.cuni.cz, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
Date: Sat, 17 Jun 2006 01:26:52 -0400	[thread overview]
Message-ID: <4493929C.6080202@myri.com> (raw)
In-Reply-To: <20060617050524.GX2387@parisc-linux.org>

Matthew Wilcox wrote:
>> We introduce whitelisting of chipsets that are known to support MSI and
>> keep the existing backlisting to disable MSI for other chipsets. When it
>> is unknown whether the root chipset support MSI or not, we disable MSI
>> by default except if pci=forcemsi was passed.
>
> I think that's a bad idea. Blacklisting is the better idea in the
> long-term.

In this case, we absolutely need an exhaustive list of chipsets that do
not support MSI. And it looks like there are a lot of them in the
non-PCI-E world. Our concern is that trying to enable MSI when it does
not work breaks drivers. While disabling MSI generally keeps drivers
working (except for instance for the Infinipath hardware, but our
whitelisting of the nVidia chipset might help them :)).
For the long term, I hope we'll end up having an exhaustive list of
chipsets that do not support MSI. But in the meantime, our "whitelisting
+ disable when we don't know" might help getting MSI as much as possible
without breaking to many things.

>
>> Bus flags inheritance is dropped since it has been reported to be broken.
>
> I must have missed that report. Please elucidate.
>

It is based on the following thread:
    http://www.ussg.iu.edu/hypermail/linux/kernel/0605.2/0929.html

The amd8131 MSI quirk cannot be EARLY or HEADER because it would be
called before dev->subordinate has been set (then, PCI_BUS_FLAGS_NO_MSI
could not be set in the bus flags). But, flags are inherited while the
PCI hierarchy is scanned, which means the quirk has to be EARLY or HEADER.
To solve this issue, we would need a quirk that is called while the PCI
hierarchy is scanned (ie, before FINAL or ENABLE) and after the pci
child bus of the bridge is created (ie, after EARLY and HEADER). But I
am not sure whether adding a new quirk type for this is a good idea.

Since the MSI is always actually processed on the root chipset, we know
we have to check there. We thought that inheriting bus flags was not
really required. That's why my patch finds the root chipset and checks
bus flags there.

Brice


  reply	other threads:[~2006-06-17  5:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-17  3:01 [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities Brice Goglin
2006-06-17  5:05 ` Matthew Wilcox
2006-06-17  5:26   ` Brice Goglin [this message]
2006-06-19 11:19   ` Xavier Bestel
2006-06-19 15:27     ` Grant Grundler
2006-06-17  6:28 ` Greg KH
2006-06-17  7:11   ` Brice Goglin
2006-06-17  8:23     ` Andi Kleen
2006-06-17 14:48       ` Brice Goglin
     [not found]         ` <20060619005329.GA1425@greglaptop>
2006-06-19  8:28           ` [discuss] " Andi Kleen
2006-06-19 12:52             ` Brice Goglin
2006-06-19 15:47             ` Greg Lindahl
2006-06-17 11:25   ` Jeff Garzik
2006-06-17 15:34 ` Alistair John Strachan
2006-06-17 16:15   ` Brice Goglin

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=4493929C.6080202@myri.com \
    --to=brice@myri.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    /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