On Mon, 7 Dec 2009, Alan Stern wrote: > > > > Make the USB host controller do its suspend asynchronously. We don't > > suspend PCI bridges anyway, iirc (but I didn't actually check). And at > > worst, we can make the PCI _bridges_ know about async suspends, and solve > > it that way - without actually making any normal PCI drivers do it. > > This sounds suspiciously like pushing the problem up a level and > hoping it will go away. (Sometimes that even works.) The "we don't suspend bridges anyway" is definitely a "hoping it will go away" issue. I think we did suspend bridges for a short while during the PM switch-over some time ago, and it worked most of the time, and then on some machines it just didn't work at all. Probably because ACPI ends up touching registers behind bridges that we closed down etc. So PCI bridges are kind of special. Right now we don't touch them, and if we ever do, that will be another issue. > In the end it isn't a very big issue. Using one vs. two passes in > dpm_suspend() is pretty unimportant. I also suspect that even if you do the USB host controller suspend synchronously, doing the actual USB devices asynchronously would still help - even if it's only "asynchronously per bus" thing. So in fact, it's probably a good first step to start off doing only the USB devices, not the controller. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
