> There's no driver infrastructure to call down to the driver to say "save > your state, but don't suspend". None. Zero. Nada. Zip. ..../... > The include files talk about PM_FREEZE, but that's a load of crap. The > whole point is to _not_ freeze things, so that you can still access the > device and save your disk image or your printk messages to it. It also > seems designed to _either_ "freeze" the machine or "suspend" the machine, > but not both. > > In other words, it's misdesigned. And I've talked about this before. Ijust > googled for it, and I saw myself ranting about this very same issue a year > ago (and back then, I also said "as I've said before"). It can't work. Unfortunately. You can't save a consistent system image if your drivers aren't all stopped and DMA is stopped. Save state and freeze have to be atomic to each other or your system image is simply not consistent (and good luck with resuming). Of course, we don't need to actually _shut_down_ devices, we only need to stop drivers, but in some cases, the only way to stop DMA is to atually stop the device... thus the blurry situation between device and driver suspending. Also, you cannot do a full system 2 pass callback mecanism (as much as I would have liked it) of the sort save state and then suspend because of the above: since save state has to stop processing of requests on all drivers in order to provide a consistent system image, by the time you reach your shutdown/suspend() callback pass, you can't talk to your actual hardware anymore because your parent driver is ... frozen. Example is USB for example: to save a consistent state, the USB host controller must stop DMA processing (for both STD and kexec). But that means it can't process requests. Thus child drivers can't communicate with their device. Thus the second pass "suspend/shutdown" will not be able to communicate with the various hardware to put them in actual suspend state. Ben.
