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

Nigel Cunningham
2006-04-25T10:34:49Z

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

Hi.

On Tuesday 25 April 2006 08:47, David Brownell wrote:
> On Monday 24 April 2006 2:47 pm, Rafael J. Wysocki wrote:
> > I agree with this change but I think it'll cause some strange things to
> > happen for some time.
>
> Let's see. :) I think it's less likely to be drivers with broken
> shutdown() callbacks than drivers which are missing them.
>
> Plus, one of the main reasons that driver suspend/resume handling
> is _still_ so goofy is that most drivers are stupid, and just reinit
> devices from scratch in their resume() methods. Drivers like that
> should not notice any difference. :)

No!

The only reason that driver suspend/resume handling is still far from perfect
is that a good number of drivers still don't have any suspend/resume
handling. Getting rid of the instrastructure because it isn't completely
implemented is the wrong approach. We should instead complete implementing
the support so that drivers understand the difference between freezing,
suspending, powering down, powering up and resuming. If we dumb things down,
we'll only create problems.

Rafael raised the issue in another email of code built as modules that is
suspended and not resumed or vice versa because in the case of suspend to
disk, the module is loaded at boot time but not in the suspended kernel (or
v.v). It seems to me that the right way to deal with this is to extend the
use of __nosave so that information about what was loaded in the boot kernel
is available when resuming drivers after the atomic restore.

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]