On Thu, 15 Jun 2006, Pavel Machek wrote: > > Okay, you _can_ do > > suspend whole tree but disk and video > freeze disk and video > create snapshot > unfreeze disk and video I really think that's totalyl unnecessary. At most, you could make the "save_state()" also say "stop listening to external stuff" for devices that otherwise do things on their own. That's not a "freeze" - the device would still obey commands coming from the host - and it would need a "unsave" logic when a suspend fails, but it doesn't change the fundamental "save means _save_, not suspend" logic. And we currently don't have _anything_ like that. Playing games with sending different commands down the "suspend()" thing is not ever going to work. Drivers are going to do it wrong. We really need to add a "save_state()" callback, and it needs to be called that, so that people realize that they should not suspend in it. It would actually simplify and clarify a lot of the confusion we have now. I already fixed one driver (sky2) that simply didn't save it's PCI state, it just suspended (and then in resume it tried to "restore" the state that had never been saved). And I _bet_ that was because it's just a very natural thing to do when you look at "suspend()" as an independent op. So it's actually important - _especially_ for device drivers - to have logical and _distinct_ operations, because device driver writers seldom see the big picture. But if you tell a device driver writer that he needs to save the state, he'll understand that. He might even understand the notion of shutting down the receive side for devices that need it. But if you tell a device driver writer that they need to write a "suspend" function, that's exactly what he will do. Linus
