On Tue, 26 Jun 2012, Grazvydas Ignotas wrote: > CCing some PM people, maybe they can comment? > > On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak <rnayak@xxxxxx> wrote: > > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote: > >> > >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n? > >> Are they supposed to handle the error values returned by runtime PM > >> functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME? > > > > hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would > > be stubbed to return success and not failure. Not exactly. They are stubbed to indicate that the device cannot be suspended, that it is always active. Failure to suspend a device should not be regarded as particularly bad, because it doesn't affect the device's functionality. That's true even when CONFIG_RUNTIME_PM is enabled. > And the _pm_runtime_resume > > function indeed seems to return 1, which is not failure but just saying > > that your device is already active/enabled. > > The _pm_runtime_suspend and _pm_runtime_idle do return a -ENOSYS, which > > is something only returned when CONFIG_RUNTIME_PM=n, so if you really > > want to handle failing pm_runtime_put_sync cases, maybe you still can. > > But then, I don't know if there is anything you can do to recover from > > a failing pm_runtime_put_sync, except for warning the user maybe. I don't see much point in warning the user that a device was unable to go to low power. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
