On Wed, 20 Feb 2008, Jesse Barnes wrote: > > The current callback system looks like this (according to Rafael and the last > time I looked): > ->suspend(PMSG_FREEZE) > ->resume() > ->suspend(PMSG_SUSPEND) > *enter S3 or power off* > ->resume() Yes, it's very messy. It's messy for a few different reasons: - the one you hit: a driver actually has a really hard time telling what PMSG_SUSPEND really means. - more importantly, we generally don't want to "suspend/resume" the hardware at all around a power-off, because we're going to resume with the state at the time of the PMSG_FREEZE, which means that the hardware has actually *changed* and been used in between! that second case is very fundamental for things like USB devices, which in theory you can hold alive over a real suspend event (ie a STR event), but which absolutely MUST NOT be resumed over a suspend-to-disk event, because all the low-level request state is bogus! So the "->resume" really isn't a resume at all. It's much closer to a "->reset". Of course, the "solution" to this all right now is that we have to reset everything even if it *is* a suspend event, so it basically means that STR ends up using the much weaker model that snapshot-to-disk uses. The fundamental problem being that the two really have nothing what-so-ever to do with each other. They aren't even similar. Never were. > And in the long term we could have: > ->suspend() > *enter S3* > ->resume() Yes, apart from all the complexities (suspend_late/resume_early). So in reality it's more than that, but the suspend/resume things are clearly nesting, and they have the potential to actually keep state around (because we *know* this machine is not going to mess with the devices in between). IOW, here we actually can have as an option "assume the device is there when you return". > or: > ->hibernate() > *kexec to another kernel to save image* > *power off* > ->return_from_hibernate() (or somesuch) Enough people don't trust kexec that I suspect the right thing simply is ->freeze() // stop dma, synchronize device state *snapshot* ->unfreeze(); // resume dma *save image* [ optionally ->poweroff() ] // do we really care? I'd say no *power off* ->restore() // reset device to the frozen one which may have four entry-points that can be illogically mapped to the suspend/resume ones like we do now, but they really have nothing to do with suspending/resuming. And notice how while "freeze/restore" kind of pairs like a "suspend/resume", it really shouldn't be expected to realistically restore the same state at all. The "restore" part is generally much better seen as a "reset hardware" than a "resume" thing. Because we literally cannot trust *anything* about the state since we froze it - we might have booted a different OS in between etc. Very different from suspend/resume. 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