On Thu, 14 Nov 2013, Ulf Hansson wrote: > > The reason for doing things the way they are is to avoid races between > > system PM callbacks and runtime PM callbacks. We don't want to have a > > runtime_resume routine powering up a device at the same time as a > > suspend routine is powering it down. > > I believe I understand why the PM core prevent this. Some subsystems > and drivers depends on this behaviour, but I wonder if we should > consider this as common cases or more like special cases? > > For those drivers that potentially could rely on runtime PM (and it's > callbacks) to inactivate the device during system suspend, and thus > don't have issues with races you describe above, the current behaviour > in the PM core adds unnecessary complexity for these drivers to handle > system suspend. What unnecessary complexity? Bear in mind that drivers _cannot_ rely on runtime PM to inactivate a device during system suspend. The user can always prevent a device from going into runtime suspend by writing "on" to the /sys/.../power/control file. > Drivers/buses/power_domains that handles runtime PM enabled devices, > will, as you also have pointed out earlier, need to implement the > .suspend callback (suspend_late or suspend_noirq might work as well) > and the corresponding .resume callback. This just for the sake of > making sure all their runtime enabled devices gets fully inactivated > during system suspend. > > I wonder if we somehow should move the responsibility of preventing > "runtime suspend" as a part of the system suspend, down to the driver > to decide instead of the PM core? No, I don't think so. It would mean that every driver's suspend routine would have to do a pm_runtime_get of some sort. It's better to just leave the single runtime_get call in the PM core. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
