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.
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".
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
--
