> > Drivers don't have to implement anything special if they want to use > their runtime routines for system suspend. All they have to do is set > the .suspend and .resume method pointers to point to their > runtime_suspend and runtime_resume routines. > >> In the case were drivers needs there runtime resourses to be activated >> to be able to handle their system suspend tasks, those can easily just >> restore the runtime PM usage count, pm_runtime_put_sync(), once done >> with it's suspend operations, which then will inactivate the device. > > 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. 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? Kind regards Ulf Hansson -- 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
