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

Hi.

On Thursday 27 April 2006 00:24, Alan Stern wrote:
> 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.

Sorry. I was using them interchangably. I meant devices, since the same driver 
might be handling more than one instance.

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

I was deliberately not worrying about that at the moment, and just assuming 
that we'd come up with some way to match the entries. My initial guess would 
be that it would involve whatever per instance ids were available, or 
something as close to that as we can manage.

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

I would think it should still be resumed at that stage. It just gets told 
(somehow) at that point that it wasn't suspended in the boot kernel, and it 
might therefore perform different actions, based on that info.

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