On Wednesday 21 June 2006 8:18 pm, Benjamin Herrenschmidt wrote: > > > Let me give you an example, just to clarify. > > > > Let's say that you have a USB host controller. It's got two kinds of > > state: the "driver state", which is basically the in-memory image, and > > which gets snapshotted separately (or, in the case of STR, just remains), > > and the "hardware state" which is basically the rest, and which is > > snapshotted by save_state(). > > USB is funny because it has shared in-memory state between driver and > controller, By which you mean I think the request queues? Those do need clearly defined sequence points for an atomic snapshot. Resending a data buffer would probably corrupt device state (either persistent or else maintained through the device suspend state), if it even works (the protocol may reject the resent request). > and the controller itself doesn't really keep any state in > hardware, so it's in fact the easy example :) Erm, controller most certainly maintains port state in hardware. Especially for "real suspend" states like STR ... example, EHCI is specified to retain that state (with Vaux power) even when other registers get reset. And that port state is critical breaks-if-corrupted state, which can't be snapshotted by software (unless correctness doesn't matter to you for some reason). > Thing is, save_state happens at any time before the actual suspend with > things still operating in between, thus there is absolutely no saying > how long that state remains valid. In the case of PCI config space, it > could have been saved at driver init time for what matters. Nope ... setpci may have been used to tweak things at runtime, and in ways that affect system correctness. Admittedly that's not the most common scenario, but I've had to use it on some systems. So saving PCI config space "late" is a far better approach. It's hardware state that _can_ be snapshotted, with care. - Dave
