On Sun, 6 Dec 2009, Alan Stern wrote: > > That's ridiculous. Having gone to all the trouble of building a device > tree, one which is presumably still almost entirely correct, why go to > all the trouble of tearing it down only to rebuild it again? (Note: > I'm talking about resume-from-RAM here, not resume-from-hibernation.) Hey, I can believe that it's worth keeping the USB device tree, and just validating it instead. However: > If I understand correctly, what you're suggesting is impractical. You > would have each driver responsible for resuming the devices it > registers. The thing is, for 99% of all devices, we really _really_ don't care. Especially PCI devices. Your average laptop will have something like ten PCI devices on it, and 99% of those have no delays at all outside of the millisecond-level ones that it takes for power management register writes etc to take place. So what I'm suggesting is to NOT DO ANY ASYNC RESUME AT ALL by default. Because async device management is _hard_, and results in various nasty ordering problems that are timing-dependent etc. And it's totally pointless for almost all cases. This is why I think it is so crazy to try to create those idiotic "this device depends on that other" lists etc - it's adding serious conceptual complexity for something that nobody cares about, and that just allows for non-deterministic behavior that we don't even want. > So consider this suggestion: Let's define PM groups. Let's not. I can imagine that doing USB resume specially is worth it, since USB is fundamentally a pretty slow bus. But USB is also a fairly clear hierarchy, so there is no point in PM groups or any other information outside of the pure topology. But there is absolutely zero point in doing that for devices in general. PCI drivers simply do not want concurrent initialization. The upsides are basically zero (win a few msecs?) and the downsides are the pointless complexity. We don't do PCI discovery asyncronously either - for all the same reasons. Now, a PCI driver may then implement a bus that is slow (ie SCSI, ATA, USB), and that bus may itself then want to do something else. If it really is a good idea to add the whole hierarchical model to USB suspend/resume, I can live with that, but that is absolutely no excuse for then doing it for cases where the hierarchy is (a) known to be broken (ie the whole PCI multifunction thing, but also things like motherboard power management devices) and (b) don't have the same kind of slow bus issues. 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
