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

["Rafael J. Wysocki" <rjw@sisk.pl>]

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

Hi,

On Tuesday 25 April 2006 00:31, Nigel Cunningham wrote:
> On Tuesday 25 April 2006 07:29, David Brownell wrote:
> > I've noticed a bunch of problem reports that go like this:
> >
> >  - boot system with some USB devices attached
> >  - echo disk > /sys/power/state
> >  - ... later resume ...
> >  - now those USB devices don't work right
> >  - unplug them/replug them, all is OK
> >
> > I recently observed this myself and tracked down one problem.  The solution
> > involves what kexec() does in much the same situation:  before starting a
> > new kernel, most hardware needs to be reset.  Today, swsusp will suspend it
> > instead, which is the root cause of the problem.
> 
> I'm not sure that it is. If we switched to not freezing devices, we'd then 
> cause issues with hardware such as hard drives. They need to know that we 
> just want things quiesced, mainly because we don't want to spin down drives.

That's right.  And kernel_restart_prepare(NULL) will make them spin down?
If so, they have to be treated in a special way.

OTOH I think at least some device driver writers assume that .resume() will
always be called after .suspend() which only is true for non-modular drivers
(or for modular drivers loaded from an initrd before resume).  The David's
change makes this assumptions explicitly invalid and that's why I said
I agreed with it.  However you're absolutely right about hard disks.

Greetings,
Rafael

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