Re: parallel suspend/resume

[Oliver Neukum <oliver@neukum.org>]

Am Samstag, 8. Dezember 2007 16:43:25 schrieb Alan Stern:
> On Sat, 8 Dec 2007, Oliver Neukum wrote:
> 
> > Am Freitag, 7. Dezember 2007 19:01:12 schrieb David Brownell:
> > > FWIW the appended patch removes that rude "order of registration"
> > > policy, so that the suspend/resume list matches the device tree.
> > > It's behaved OK on PCs and, in light duty, a few development boards;
> > > I've carried it around most of this year.
> > 
> > As it is a tree, why not store it as such?
> 
> There's no need to "store" the tree ordering specially, since all the
> pointers already exist.  The question is: In what order should the tree

Nevertheless, we currently have a list. Why? To reverse the temporal order
only?

> be traversed?  About the only explicit constraint we have now is that
> children must be suspended before their parents, but there undoubtedly
> are plenty of undocumented implicit constraints (maybe some of them
> aren't known to anybody at all).

We will need to know them for runtime pm.

> Given the vast number of possible orders, and given that the only order 
> we _know_ works correctly is reverse order of registration, I don't see 

modus advocati diaboli:

Suppose I have a system with a FibreChannel disk. Now I hot plug another
FibreChannel controller and connect it to the disk. Then I disconnect the disk
from the original controller. What will happen if I suspend the system?

> any big reason to change.  Speeding things up by parallel suspension 
> would be a valid reason, but it needs to be done with a great deal of 
> care.

catch-22.

	Regards
		Oliver