On Mon, 14 Dec 2009, Rafael J. Wysocki wrote: > > OK, what about a two-pass approach in which the first pass only inits the > completions and starts async threads for leaf "async" devices? I think leaf > devices are most likely to take much time to suspend, so this will give us > a chance to save quite some time. Why? Really. Again, stop making it harder than it needs to be. Why do you make up these crazy schemes that are way more complex than they need to be? Here's an untested one-liner that has a 10-line comment. I agree it is ugly, but it is ugly exactly because the generic device layer _forces_ us to wait for children even when we don't want to. With this, that unnecessary wait is now done asynchronously. I'd rather do it some other way - perhaps having an explicit flag that says "don't wait for children because I'm not going to suspend myself until 'suspend_late' _anyway_". But at least this is _simple_. Linus --- drivers/pci/probe.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 98ffb2d..4e0ad7b 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -437,6 +437,17 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent, } bridge->subordinate = child; + /* + * We don't really suspend PCI buses asyncronously. + * + * However, since we don't actually suspend them at all until + * the late phase, we might as well lie to the device layer + * and it to do our no-op not-suspend asynchronously, so that + * we end up not synchronizing with any of our child devices + * that might want to be asynchronous. + */ + bridge->dev.power.async_suspend = 1; + return child; } -- 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
