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

[Nigel Cunningham <nigel@suspend2.net>]

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

Hi.

On Wednesday 26 April 2006 06:53, Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday 25 April 2006 22:28, Nigel Cunningham wrote:
> > On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote:
> > > You're saying that (9) is wrong, so could you please suggest what to do
> > > instead of it?
> >
> > 'scuse me for butting in, but here's my suggested modified version:
> > > Well, suppose we have a modular driver that's not loaded before resume.
> > > Then it goes like that (approximately):
> > > (1) We activate swsusp which calls .suspend() for all devices including
> > > our driver (this is a real suspend).
> > > (2) swsusp snapshots the system and creates the image.
> > > (3) swsusp calls .resume() for all devices in order to be able to save
> > > the image (.resume() for our driver is also called which is OK).
> > > (4) swsusp turns off the system.
> > > (5) (some time later) We start a new kernel and tell it to resume.
> > > (6) It activates swsusp which reads the image.
> > > (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.
>
> Do you mean we place the list in a __nosave area?

Well, I wasn't wanting to get bogged down in the details yet, but let's see 
what we can come up with. How about this:

At the point where we do the drivers resume at resume time, we're still 
atomic, right? Since that's the case, we can just use get_safe_page() prior 
to the restore to store the list and a __nosave pointer to retain the 
location across the atomic restore. If we are concerned about resuming 
drivers allocating memory and overwriting our list (and I think that's a 
valid concern), space could be allocated and the list copied between doing 
the atomic restore and the device pwoerup/resume. Another approach might be 
to allocate space for the list while suspending (prior to the atomic copy), 
but that could cause problems since you don't know how many devices will be 
in the list ahead of time. Are there other possibilities I haven't thought 
of?

Regards,

Nigel

-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]