Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities

[Brice Goglin <brice@myri.com>]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/