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

Rafael J. Wysocki
2006-04-25T08:32:56Z

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