USB persist is a sysfs-controlled per-device kernel feature that makes the kernel re-enumerate devices that lost their power session in S3 synchronously on resume and pretend to userspace that they never went away. This is useful for certain use cases (e.g. having a mass storage device mounted) which aren't particularly relevant to Chrome OS, but it comes with serious resume time penalties (because device enumeration takes hundreds of milliseconds). That's why we had always disabled it on Chrome OS.

However, hubs are hardcoded in the kernel to always use persist... presumably to make it easier for userspace to control (because having persist enabled on a device wouldn't help unless it is also enabled on all its parent devices). This means that when users have a hub plugged in (as may become increasingly common with the rise of Type-C) their resume time may regress by roughly 500ms (see issue 726508 for examples).

We should try to change the kernel to remove this restriction so that we can stop reenumerating hubs synchronously. This will probably take some amount of convincing upstream. Feedback from people like Alan Stern would also be very helpful to make sure we're getting it right and not overlooking any important aspect. Some important detail questions: should root hubs still have the persist flag set, or what happens if they don't? (Root hubs usually require much less time to reset and enumerate, although it's not zero.) Do we need to programmatically prevent userspace from enabling persist on a device unless all its parents have it, or would it just fail gracefully? Should we maybe transparently enable it on the parents in that case?