Tuesday, November 16, 2010, 5:33:48 PM, you wrote: > On Tue, Nov 16, 2010 at 05:29:15PM +0100, Clemens Ladisch wrote: >> Greg KH wrote: >> > On Tue, Nov 16, 2010 at 05:06:31PM +0100, Clemens Ladisch wrote: >> > > But would you accept patches that make the drivers test, when attaching, >> > > whether the MSI interrupt actually works, and fall back to INTx >> > > otherwise? This would break only for devices that blow up completely >> > > when configured for MSI; I don't know if or how many of those exist. >> > >> > That would be better, but again, is this all really worth it? What >> > benifits will MSI for usb controllers accomplish? >> >> On many chipsets, the onboard USB controllers all share the same >> interrupt, or share their interrupts with lots of other devices. >> Using MSI allows the handlers to run concurrently on different CPU >> cores, and might protect other devices against interrupt storms if >> a device or driver fails. > But is that a failure that anyone has ever reported? > I don't see the benefit of adding this and dealing with the fallout of > lots of broken systems that previously were working just fine. > Do you? > greg k-h I guess that's why Clemens put it as a module option in the first place ? Another way could be to use the fallback scenario, and try it first in linux-next for a while, if that still gives a lot of problems in practice, revert and make it a module option ? -- Sander -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
