On Thu, 15 Jun 2006, Alan Stern wrote: > > If this happens you're already in trouble. It doesn't matter that the > unrelated devices aren't suspended; the fact that they have already saved > their state and will no longer respond to outside stimuli means they can't > be used. Not to mention that their I/O queues won't be running. THEIR IO QUEUES ARE RUNNING! Why are people being dense and stupid? I told you in the very first explanation that the IO state isn't suspended by "save_state()". "save_state()" would not disable the device. It would not disable the queues. The device would remain usable, and 100% functional. It also would NOT save any "queue state". That's a total software abstraction, and that's something that comes much later (if at all), when we actually need to save the memory image. The only thing the "save_state()" needs to save is the actual _hardware_ state, and not even all of that. For example, on resume, if you have a network device, you SHOULD NOT EVEN TRY to resume the queue state. It's irrelevant. You should consider all queued packets (on a hardware level) from before the suspend to be _gone_. You re-initialize the hardware, but you need to restore things like the BAR's etc that were set up originally. If you screw up and stop devices from working in "save_state()", that would be a BUG. > Suppose a driver needs to store its state info on a networked drive and > the network interface has already saved _its_ state? Or it needs to > access a USB drive and the USB controller is no longer doing DMA? So? The network device didn't save the state of the _software_. It doesn't need to. It doesn't need to save the state of the DMA areas - they should be RE-DONE by the resume code. The only thing it needs to save is the actual state of the hardware itself, and in fact, if it knows the hardware intimately and there is no state that got set up "outside" of the driver, it doesn't need to save even that. It's perfectly ok to save zero state at all, if you know that you can re-create the state from the "dev->resources[]" data, for example. > There is a clear need for a partial ordering of devices. If device A > needs to use device B to save its state, then A's state must be saved > before B's. NO. NO. NO!! Get it though your head that savign state doesn't change it. Neither does normal operations. Because normal operations don't actually change the STATE of a device - they just change the immaterial details that your driver has to keep track of _independently_, and are things that a reset needs to set up _anyway_. Realize that a "resume" event is not really any different from a "boot" event, except that - you haven't had a firmware POST setting up the device (this is a _huge_ issue for video devices, for example) - you have some previously cached state like virtual MMIO mappings etc that you had set up one way before the resume, and that means that you have to set up _those_ details the same way (or, you need to unmap the old VM state and re-map it with the new one you create: that's a perfectly valid operation too) But things like queues etc are not about the device any more. You're literally better off just flushing them. Trying to save/restore bit-for-bit same exact state is impossible and/or just a huge waste of time. Linus
