Re: [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()

[David Brownell <david-b@pacbell.net>]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Tuesday 25 April 2006 3:18 pm, Nigel Cunningham wrote:

> I saw the 2 suspends, 1 resume comment in another part of the thread, but 
> don't believe a driver would be able to detect that 2 suspends and 1 resume 
> call had been made - at least not without some non volatile ram.

The extra suspend is just IMO a symptom of sloppiness, like a "here may be bugs"
sign.  Not necessarily an issue in its own right.

In fact if you count carefully, it's three suspends and one resume:  one
suspend before calling swsusp_resume, one inside swsusp_resume -- replaced
by my patch -- and a correctly matched pair in the kernel being resumed.

Raising two points:  (1) for those who think suspend is right, you can
think of it as replacing one of the extra ones with kernel_restart_prepare();
and (2) not very much code interacts with that restart prep, that's a
sane audit problem.


Also, about non-volatile RAM.  Not necessary ... the device hardware holds all
the relevant state.  The problem is that swsusp is now trashing it with those
suspend calls before resuming the real kernel.  On the plus side, we already
have code being used to resolve the identical issue for kexec(), and all my
patch does is to use it.

- Dave



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]