On Tue, 1 Apr 2008, Rafael J. Wysocki wrote: > > If the device is gone, it doesn't much matter what resume() returns. > > Yes, it does. In that cases, the error code would tell the PM core not to attempt > to resume the device's children etc. If the device is gone then so are its descendants, right? So it doesn't matter whether the PM core tries to resume them. > Otherwise, it's quite meaningless to the > PM core, because it really can mean anything and how's the PM core supposed > to handle _that_? Exactly. This is the point I was trying to make a week or so ago. > Either we decide that the error codes returned by ->resume() mean critical > errors or there's no point in returning error codes from ->resume() at all > (other than logging the errors by the core). > > Well, that's getting confused. I think I'll have to rework the patch not to > really handle the errors returned by ->resume() and friends, after all, but > I'll keep the reporting of them. > > However, I'd like to add a recommendation that the _new_ "resume" callbacks > should only return errors in critical situations as the indication to the PM > core that something went _really_ wrong and the device in question is quite > surely unusable. Agreed. The most important aspect is that drivers should _not_ return an error if the device is working correctly. We should fix the drivers which make this mistake. 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
