public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: parallel suspend/resume
Date: Sat, 8 Dec 2007 21:46:46 +0100	[thread overview]
Message-ID: <200712082146.47165.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0712071414210.27132-100000@netrider.rowland.org>

On Friday, 7 of December 2007, Alan Stern wrote:
> On Fri, 7 Dec 2007, David Brownell wrote:
> 
> > > What about ordering constraints?  A lot of them aren't explicit.  We 
> > > just depend on the fact that devices get suspended in reverse order of 
> > > registration.  You can't do that in parallel.
> > 
> > Those constraints should *become* explicit ... not stay implicit!
> 
> Why do I get the feeling we've gone through this before?  :-)
> 
> > FWIW the appended patch removes that rude "order of registration"
> 
> "Rude"?  What's rude about it?  It seems most logical to me: Since the
> devices obviously worked in the intermediate stages of registration,
> when the early-to-register devices were available and the
> late-to-register devices weren't, duplicating those same intermediate
> stages (with the same sets of devices available) should also work
> during suspend.
> 
> > policy, so that the suspend/resume list matches the device tree.
> 
> In what respect doesn't it match the device tree now?
> 
> As far as I know, the only way in which the list wouldn't match the
> tree is when the tree gets reorganized by device_move(), which doesn't
> change the list at all.  (This is quite possibly a bug.)

IMO, this _is_ a bug.  I think device_move() should move the device in question
to the end of the list along with its children.

That might cause some breakage in the short run, but we'll have to do it at one
point.

Greetings,
Rafael

  reply	other threads:[~2007-12-08 20:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08 19:46 parallel suspend/resume Marcelo Tosatti
2007-10-09 15:54 ` Alan Stern
2007-12-07 15:51 ` Pavel Machek
2007-12-07 16:22   ` Alan Stern
2007-12-07 18:01     ` David Brownell
2007-12-07 19:33       ` Alan Stern
2007-12-08 20:46         ` Rafael J. Wysocki [this message]
2007-12-10  5:10         ` David Brownell
2007-12-10 17:57           ` Alan Stern
2007-12-08  8:00       ` Oliver Neukum
2007-12-08 10:21         ` Pavel Machek
2007-12-08 11:08           ` James Courtier-Dutton
2007-12-08 12:26             ` Oliver Neukum
2007-12-08 11:24           ` Oliver Neukum
2007-12-08 15:43         ` Alan Stern
2007-12-08 20:43           ` Rafael J. Wysocki
2007-12-09 13:23           ` Oliver Neukum
2007-12-09 15:31             ` Alan Stern
2007-12-08 16:26       ` Alan Stern
2007-12-08 22:00         ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200712082146.47165.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox