On Tue, 15 Dec 2009, Linus Torvalds wrote: > > And even when you know it's PCI, our rules are actually not simple at all. > Our rules for PCI devices (and this strictly speaking is true for bridges > too) are rather complex: > > - do we have _any_ legacy PM support (ie the "direct" driver > suspend/resume functions in the driver ops, rather than having a > "struct dev_pm_ops" pointer)? If so, call "->suspend()" > > - If not - do we have that "dev_pm_ops" thing? If so, call it. > > - If not - just disable the device entirely _UNLESS_ you're a PCI bridge. > > Notice? The way things are set up, if you have no suspend routine, you'll > not get suspended, but you will get disabled. Side note - what I think might be a clean solution for PCI at least is to do something like the following: - move that "disable the device entirely" thing to suspend_late, rather than the earlier suspend phase. Now PCI devices without drivers or PM will not be touched at all in the first suspend phase. - initialize all PCI devices to have 'async_suspend = 1' on discovery - whenever we bind a driver to the PCI device, we'd then look at whether that driver implements suspend/resume callbacks (legacy or new), and clear the async_suspend bit if so. That way we'd have the same old synchronous behavior for all PCI suspend and resume events (unless the driver itself then sets the async_suspend bit at device init time, which it could do, of course), while still always doing async "no-op" events. That would avoid the ugly one-liner that just "knows" that PCI bridges are special and don't do anything at suspend time (even though they aren't really - a PCI bridge _could_ have a driver associated with it that does something that might not be happy being asynchronous). 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
