Re: [PATCH 2/2] Fix console handling during suspend/resume

David Brownell
2006-06-22T05:52:31Z

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