Messages in this thread |  | | | Date | Sat, 17 Jun 2006 01:26:52 -0400 | | From | Brice Goglin <> | | Subject | Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities |
| |
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/
|  |