On Mon, 18 Nov 2013, Ulf Hansson wrote: > I favour the pm_runtime_no_prevent_suspend API approach, since it > would mean a change in behaviour of the PM core. That's exactly why I don't favor it! :-) > I also think that in > some cases it could make runtime PM better understandable, for those > who are deploying it. I don't see how it would make runtime PM either more or less understandable, since the proposed change affects system PM, not runtime PM. On the other hand, it would make the Runtime PM documentation more complicated. (Also, I think the name "pm_runtime_no_prevent_suspend" is a very bad choice. It should be something more like "allow_runtime_suspend_during_system_sleep".) > Another advantage of "pm_runtime_no_prevent_suspend" is that driver's > can still easily prevent runtime suspend, during system suspend, by an > extra call to "pm_runtime_get*". Typically this could be used when the > device is configured for wakeup. How is this an advantage? Drivers can accomplish the same thing right now by not doing anything at all. > In this case the generic suspend_late > approach would not work, since the driver would need to implement it's > own .suspend_late callback to handle this. Actually, drivers would simply need to _avoid_ setting the .suspend_late callback. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
