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

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- 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 --]