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

Alan Stern
2009-12-09T15:24:04Z

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