On Sun, 2009-12-06 at 23:23 +0800, Alan Stern wrote: > On Sat, 5 Dec 2009, Linus Torvalds wrote: > > > Think of a situation that we already handle pretty poorly: USB mass > > storage devices over a suspend/resume. > > > > > The device tree represents a good deal of the dependences > > > between devices and the other dependences may be represented as PM links > > > enforcing specific ordering of the PM callbacks. > > > > The device tree means nothing at all, because it may need to be entirely > > rebuilt at resume time. > > Nonsense. > > > Optimally, what we _should_ be doing (and aren't) for suspend/resume of > > USB is to just tear down the whole topology and rebuild it and re-connect > > the things like mass storage devices. IOW, there would be no device tree > > to describe the topology, because we're finding it anew. And it's one of > > the things we _would_ want to do asynchronously with other things. > > That's ridiculous. Having gone to all the trouble of building a device > tree, one which is presumably still almost entirely correct, why go to > all the trouble of tearing it down only to rebuild it again? (Note: > I'm talking about resume-from-RAM here, not resume-from-hibernation.) > > Instead what we do is verify that the devices we remember from before > the suspend are still there, and then asynchronously handle new devices > which have been plugged in during the meantime. Doing this involves > relatively little extra or new code; most of the routines are shared > with the runtime PM and device reset paths. > > As for asynchronicity... At init time, USB device discovery truly is > asynchronous. It can happen long after you log in (especially if you > don't plug in the device until after you log in!). But at resume time > we are more highly constrained. User processes cannot be unfrozen > until all the devices have been resumed; otherwise they would encounter > errors when trying to do I/O to a suspended device. (With the runtime > PM framework this is much less of a problem, but plenty of drivers > don't support runtime PM yet.) > > > > We don't want to build up some irrelevant PM links and callbacks. We don't > > want to have some completely made-up new infrastructure for something that > > we _already_ want to handle totally differently for init time. > > > > IOW, I argue very strongly against making up something PM-specific, when > > there really doesn't seem to be much of an advantage. We're much better > > off trying to share the init code than making up something new. > > If I understand correctly, what you're suggesting is impractical. You > would have each driver responsible for resuming the devices it > registers. If it registered some children synchronously (during the > parent's probe) then it would resume them synchronously (during the > parent's resume); if it registered them asynchronously then it would > resume them asynchronously. In essence, every single device_add() or > device_register() call would have to be paired with a resume call. > > To make such significant changes in every driver would be prohibitively > difficult. What we need is a compromise which gives drivers control > over the resume process without making them responsible for actually > carrying it out. > > So consider this suggestion: Let's define PM groups. Each device > belongs to a group, and each group (except group 0, the initial group) > has an owner device. By default a device is added to its parent's > group during registration, but the driver can request that it be > assigned to a different group, which must be owned by that parent. > > During resume, each PM group would correspond to an async task. The > devices in each group would be resumed sequentially, in order of > registration, but asynchronously with respect to other groups. The > async thread to resume a group would be launched after the group's > owner device was resumed. > yes, we've talked about something similar to this before. :) Hi, Linus, can you please look at this patch set and see if the idea is right? http://marc.info/?l=linux-kernel&m=124840449826386&w=2 http://marc.info/?l=linux-acpi&m=124840456826456&w=2 http://marc.info/?l=linux-acpi&m=124840456926459&w=2 http://marc.info/?l=linux-acpi&m=124840457026468&w=2 http://marc.info/?l=linux-acpi&m=124840457126471&w=2 If yes, I'll pick them up again and rework a patch set, including some good thoughts from Rafael. thanks, rui > So for example, the sibling functions on a PCI card could all be > assigned to the same group, but different cards could belong to > different groups. Likewise for ATA and PCMCIA controllers. Extra > cross-group constraints could be added if needed, but there should be > relatively few of them. > > This way drivers can decide which of their devices will be resumed in > sequence or concurrently, but they won't have to do any of the > necessary work. > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
