On 14 November 2013 16:55, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 14 Nov 2013, Ulf Hansson wrote: > >> > If you want a driver to do the same thing for runtime PM and system >> > suspend/resume, point its .suspend_late() and .runtime_suspend() to the >> > same routine and analogously for .runtime_resume() and .resume_early() >> > (that may not work for PCI, though, because of the _noirq stuff, but that's >> > the PCI bus type issue). >> >> When your .suspend_late callback gets called, your device may be >> either active or inactive from runtime PM point of view. Just pointing >> the .suspend_late callback to the .runtime_suspend callback, simply >> wont work. >> >> That would mean we might end up in trying to inactivate an already >> inactivated device, which I doubt is a good thing.:-) Some additional >> code will be needed to track the "runtime state" and to act >> accordingly. This is what drivers already tries to handle as of today, >> though so far mostly from their .suspend callbacks I believe. > > You could write a "generic" suspend_late routine that would invoke the > driver's runtime_suspend routine if the device's runtime PM status was > RPM_ACTIVE. > I started drafting a new RFC according to your suggestion. Soon I realized that using such a callback for .suspend_late will make drivers/buses system suspend to depend on runtime suspend, (which my RFC also has problem with). So I guess this is not a recommended set up from the PM maintainers. Wandering in circles... :-) 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
