On Sun, 6 Dec 2009, Rafael J. Wysocki wrote: > > While the current settings are probably unsafe (like enabling PCI devices > to be suspended asynchronously by default if there are not any direct > dependences between them), there are provisions to make eveything safe, if > we have enough information (which also is needed to put the required logic into > the drivers). I disagree. 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. 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. 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. > I'd say if there's a worry that the same register may be accessed concurrently > from two different code paths, there should be some locking in place. Yeah. And I wish ACPI didn't exist at all. We don't know. And we want to _limit_ our exposure to these things. Linus -- 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
