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: 1412 bytes --]

On Tuesday 25 April 2006 1:32 am, Rafael J. Wysocki wrote:

> > 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.

Seems every time that someone turns up one of the problems with this "freeze"
thing, the same responses come back:  "we can't fix that because we don't want
to spin down drives".

I've begun thinking that calls like pm_should_I_spin_down_drives() would be a
better structural approach than continually redefining this "freeze" thing so
it makes less and less sense to all other drivers ... who nonethless need to
clutter themselves up with a growing list of special cases, to accomodate
rotating media that may not even exist in the target system.


> 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). 

Say what?  Of _course_ resume() should only be called after suspend().  If
that's not true in any case, the code wrongly issuing the resume() is buggy.

I don't see where you're collecting that list of special cases.  It doesn't
match what I've observed ... and even if it were correct, I'd say that's yet
another case where special casing reflects bugs.

- Dave

  

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