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

Alan Stern
2006-04-26T14:24:00Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1401 bytes --]

A little behind the current head of the thread, but better late than
never...

On Wed, 26 Apr 2006, Nigel Cunningham wrote:

> > (7) (without your change) swsusp calls .suspend() for all device drivers
> > that are present at that time, but our driver is not there, so its
> > .suspend() _won't_ be called. [Of course with your change .suspend() won't
> > be called for any driver.]
>
> We also make a list that is safely available after the atomic restore of
> drivers that have had .suspend methods called.
>
> > (8) swsusp restores the image.
>
> (9) suspend to disk calls .resume() for each device that is found in the list
> generated above, thereby excluding our problem driver. Drivers which are
> present but not in the list above (such as the problem driver) have a
> different routine called, perhaps the normal initialisation one?

First, is this a list of drivers or a list of devices? Under (7) you said
drivers, and under (9) you said devices.

Second, how do you tell whether a device or driver in the resuming kernel
is in the list or not? Do you store the driver's name in the list and
compare names?

Third, suppose a driver was present in the original swsusp kernel (and
hence also in the resuming kernel) but not in the boot kernel. Then it
won't be in the list. Apparently that means it doesn't get resumed during
(9). So when does it get resumed?

Alan Stern

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