Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

[Alan Stern]

On Tue, 8 Dec 2009, Linus Torvalds wrote:

> On Tue, 8 Dec 2009, Alan Stern wrote:
> > 
> > You mean, if A comes before B in the list and A must suspend after B?  
> 
> But if they are not topologically ordered, then A wouldn't necessarily be 
> before B on the list in the first place.

Okay, I see what you're getting at.  Yes, this is quite true -- if A
doesn't precede B in dpm_list then A can't safely wait for B to
suspend.  To put it another way, only list-compatible constraints are
feasible.

This shouldn't be a problem.  If it were we'd be seeing it right now, 
because A would _always_ suspend before B.

> Of course, if we've mucked with the list by hand and made sure the 
> ordering is ok, then that's a different issue. But your whole point seemed 
> to be that the device could impose its own ordering in its suspend 
> callback, which is not true on its own without external ordering.

No, sorry for not making it clearer.  I was assuming all long that the 
non-tree constraints were compatible with the list ordering.

In fact these considerations already affect the USB resume operations, 
even without asynchronous resume.  The code relies on the fact that the 
PCI layer registers sibling devices on a slot in order of increasing 
function number.  There's no guarantee this will remain true in the 
future (it may already be wrong AFAIK), so putting in some explicit 
list manipulation is the prudent thing to do.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/