Hello, On Wed, Sep 18, 2013 at 06:50:45PM +0200, Alexander Gordeev wrote: > Actually, I do not see much contradiction with what I proposed. The > key words here "determine the number of MSIs the controller wants". > > In general case it is not what pci_msix_table_size() returns (or at > least we should not limit ourselves to it) - there could be non- > standard means to report number of MSIs: hardcoded, version-dependant, > device-specific registers etc. > > Next, if we opt to determine the number of MSIs by non-MSI standard > means then there is no reason not to call pci_get_msix_limit() (or > whatever) at this step. Yeah, that's all fine. My point is that we shouldn't try to use "degraded" multiple MSI mode where the number of MSIs allocated is smaller than performing full multiple MSI operation. How that number is determined doesn't really matter but that number is a property which is solely decided by the device driver, right? If a device needs full multiple MSI mode, given specific configuration, it needs >= X number of MSIs and that's the number it should request. > Being Captain Obvious here, but it is up to the device driver to handle > a failure. There could be no such option as single MSI mode after all :) I don't think there actually is a mainstream device which can't fallback to single interrupt. Anyways, the point is the same, let's please not try to create an interface which encourages complex retry logic in its users which are likely to involve less traveled and tested paths in both the driver and firmware. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
