On Tue, Nov 16, 2010 at 05:41:46PM +0100, Sander Eikelenboom wrote: > 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 ? Module options suck. Seriously, they are a pain and no one uses them. > 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 ? No, linux-next does not get very wide testing at all for something like this. Again, I fail to see any real benifit for this change, and lots of problems that can occur. thanks, greg k-h -- 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
