Re: parallel suspend/resume

Alan Stern
2007-12-07T19:33:03Z

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.) Your patch
doesn't affect that.

> It's behaved OK on PCs and, in light duty, a few development boards;
> I've carried it around most of this year.

I predict it will cause failure of the USB-Persist mechanism when a
non-high-speed device is plugged into a dual high/full-speed port.
This is because when an EHCI root hub is resumed after a loss of power,
the driver looks for ports that had been owned by the companion
controllers and tries to hand them over again -- but if the companion
controllers haven't been resumed yet the handover won't work.

However to be fair, about the best one can say for the current way this
situation is handled is that it works more or less by coincidence (EHCI
controllers are required by the spec to have higher function numbers
than their companion controllers on a PCI board, and PCI devices are
enumerated in increasing order by function number). I have to agree
that this ordering dependency really should be made explicit.

> I'd expect this to eventually turn up some cases where Linux is
> right now doing a bad job of exposing devices with multiple such
> ordering constraint ... power management via I2C seems likely to
> turn up a few of them. We'd need some automatic way to detect
> and report such problems so that they could be fixed.

If you really want to sniff out dependencies, you should add each new
device to the list at a _random_ position, subject only to the
constraint that it must not precede its parent!

Alan Stern