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

David Brownell
2006-06-15T02:48:22Z

On Wednesday 14 June 2006 6:54 pm, Nigel Cunningham wrote:

> > And quite frankly, until we do it the way I say we should do it, I don't
> > think you can _ever_ do things well. For example, the whole thing where we
> > have hacks to try to avoid suspending the device that is the disk to
> > suspend to all comes from this same problem.
>
> There I'm not so sure - I think the issue there is that we didn't
> distinguish between 'stop activity' and 'power down'.

Wheras I'd say the issue is just that pm_message_t has been a
confusing thing from day one ... it took the place of a parameter
which originally indicated a target _system_ state, but which was
widely misinterpreted as a PCI_Dx state, and is currently ignored
by all except maybe 5% of the device drivers in Linux (so that
opinions about its semantics can be rather varied).

> If I'm up
> with the play, that's being addressed in those new patches to
> add a _FREEZE state.

The only new thing discussed in that area is a new PM_EVENT_PRETHAW,
to address a device state machine botch that's specific to the current
resume-from-swsusp logic. Real system suspend states (standby, STR)
don't create those specific issues.

Actually it would be interesting to hear counter-arguments to this
position:

We already HAVE that two-phase thing going on, at
least for swsusp. In phase I a PM_EVENT_FREEZE
gets sent. Then in phase II a PM_EVENT_SUSPEND gets
tries to really suspend things.

One counter-argument might be that "phase I.5 resumes those devices"
is a problem. Another might be that "FREEZE should not be sent to
the console(s), the swap device, or their parents". I suspect there
are a few more issues mixed up in there too.

- Dave