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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux