On Mon, 7 Dec 2009, Alan Stern wrote: > > Okay, I think I've got it. But you're wrong about one thing: Resume > isn't _exactly_ the reverse of suspend. Yeah, no. But I think I made it much closer by getting rid of pre-suspend and post-resume (my next email to the one you quoted). And yeah, I started thinking along those lines exactly because it wasn't as clean a mirror image as I thought it should be able to be. > A non-async driver (i.e., most of them) would ignore the pre- pass > entirely and do all its work in the second pass. See my second email, where I think I can get rid of the whole second pass thing. I think you'll agree that it's an even nicer mirror image. > There's some question about what to do if a suspend or resume fails. A > bunch of async threads will have been launched for other devices, but > now there won't be anything to wait for them. It's not clear how this > should be handled. I think the rule for "suspend fails" is very simple: you can't fail in the async codepath. There's no sane way to return errors, and trying to would be too complex anyway. What would you do? In fact, even though we _can_ fail in the synchronous path, I personally consider a device driver that ever fails its suspend to be terminally broken. We're practically always better off suspending and simply turning off the power than saying "uh, I failed the suspend". I've occasionally hit a few drivers that caused suspend failures, and each and every time it was a driver bug, and the right thing to do was to just ignore the error and suspend anyway - returning an error code and trying to undo the suspend is not what anybody ever really wants, even if our model _allows_ for it. (And the rule for "resume fails" is even simpler: there's nothing we can really do if something fails to resume - and that's true whether the failure is synchronous or asynchronous. The device is dead. Try to reset it, or remove it from the device tree. Tough). 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
