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: Cornelia Huck <cornelia.huck@de.ibm.com>,
	linux-pm@lists.linux-foundation.org,
	Marcel Holtmann <marcel@holtmann.org>
Subject: Re: Re: Possible problem with device_move()
Date: Wed, 1 Aug 2007 21:25:15 +0200	[thread overview]
Message-ID: <200708012125.15755.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0708011316250.2663-100000@iolanthe.rowland.org>

On Wednesday, 1 August 2007 19:35, Alan Stern wrote:
> On Wed, 1 Aug 2007, Cornelia Huck wrote:
> 
> > On Wed, 1 Aug 2007 11:22:12 -0400 (EDT),
> > Alan Stern <stern@rowland.harvard.edu> wrote:
> > 
> > > As it stands right now, every place device_move() gets called is 
> > > already special!
> > 
> > The "special cases" I was thinking about are those where the order to
> > suspend/resume is not covered by a parent/child relationship, but by
> > (possibly random) order of registration. I'd have thought the rule "the
> > child must be suspended before the parent" was pretty straightforward,
> > but...
> 
> So you mean additional requirements, like what I encountered with EHCI.  
> It's peculiar in that the controller contains a hardware switch which
> can literally connect a USB device to a different (companion)
> controller, and setting the switch before the companion controller has
> been resumed won't work.  The correct way to handle this would be to
> set the switch later when the USB device is resumed, but that would be
> much more awkward.
> 
> I haven't heard of any other cases.

Well, that's really exceptional and I have no idea how to handle things like
that in a generic way.

> > (The whole list based on registration order thing seems a bit fragile
> > to me, but I don't know enough of the PM core and suspend/resume in
> > general to make a better suggestion :/)
> 
> It hasn't been bad in the past.  If A was discovered before B then ipso 
> facto it is safe to suspend B before suspending A.  Likewise, in the 
> absence of device_move, if A was discovered before B then A cannot 
> appear below B in the device tree.  Of course, this assumes devices are 
> registered as they are discovered.

Which is a weak assupmtion ...

Well, we seem to have some examples of possible situations in which the
design might not be adequate and that's alarming.

Perhaps we should create dpm_active right before the suspend, by really
traversing the device tree, when we own all device semaphores and no device
objects can be added/removed?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

  reply	other threads:[~2007-08-01 19:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-28 15:36 Possible problem with device_move() Alan Stern
2007-07-30  6:42 ` Cornelia Huck
2007-07-30 17:34   ` Alan Stern
2007-07-31  8:33     ` Cornelia Huck
2007-07-31 15:11       ` Alan Stern
2007-07-31 15:27         ` Rafael J. Wysocki
2007-07-31 15:30         ` Cornelia Huck
2007-07-31 18:17           ` Alan Stern
2007-07-31 19:12             ` Rafael J. Wysocki
2007-07-31 20:37               ` Alan Stern
2007-08-01 13:03                 ` Cornelia Huck
2007-08-01 15:22                   ` Alan Stern
2007-08-01 17:04                     ` Cornelia Huck
2007-08-01 17:35                       ` Alan Stern
2007-08-01 19:25                         ` Rafael J. Wysocki [this message]
2007-08-01 20:27                           ` Alan Stern
2007-08-02  8:06                             ` Cornelia Huck
2007-08-02 14:19                               ` Alan Stern
2007-08-02 14:50                                 ` Cornelia Huck
2007-08-02 11:21                             ` Rafael J. Wysocki
2007-08-02 14:24                               ` Alan Stern
2007-08-02 14:58                                 ` Rafael J. Wysocki
2007-08-02 15:23                                   ` Alan Stern
2007-08-02 22:39                                     ` Rafael J. Wysocki
2007-08-03 14:56                                       ` Alan Stern
2007-08-03 21:39                                         ` Rafael J. Wysocki
2007-08-06  9:31                                           ` Cornelia Huck
2007-08-06 13:53                                             ` Alan Stern
2007-07-30  6:53 ` Marcel Holtmann
2007-07-30 17:37   ` 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=200708012125.15755.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=cornelia.huck@de.ibm.com \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=marcel@holtmann.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