Re: [PATCH] PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected (was: Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled)

From: Rafael J. Wysocki
Date: Tue Nov 18 2014 - 15:19:41 EST

On Tuesday, November 18, 2014 09:34:11 AM Pavel Machek wrote:
> On Tue 2014-11-18 01:39:06, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >
> > The number of and dependencies between high-level power management
> > Kconfig options make life much harder than necessary. Several
> > conbinations of them have to be tested and supported, even though
> > some of those combinations are very rarely used in practice (it
> > they are used in practice at all). Moreover, the fact that we
> > have separate independent Kconfig options for runtime PM and
> > system suspend is a serious obscacle for integration between
> > the two frameworks.
> >
> > To overcome these difficulties, always select PM_RUNTIME if PM_SLEEP
> > is set. Among other things, this will allow system suspend callbacks
> > provided by bus types and device drivers to rely on the runtime PM
> > framework regardless of the kernel configuration.
> 3.18-rc5 still has:
> config PM_RUNTIME
> bool "Run-time PM core functionality"
> depends on !IA64_HP_SIM
> ---help---
> So I assume this patch is against tree where PM_RUNTIME does not
> depend on anything?


> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > ---
> >
> > As a follow up.
> >
> > Note that we won't need the patch making genpd select PM_RUNTIME with this,
> > because genpd already depends on PM.
> Looking through the config file, there are more config options that
> should be stripped.
> bool "Enable freezer for suspend to RAM/standby" \
> "Turning OFF this setting is NOT recommended! If in doubt, say Y."

Yeah, I'll gladly apply a patch removing this one. :-)

> bool
> ...can we just use CONFIG_HIBERNATE, instead?

We do, but in addition.

HIBERNATE_CALLBACKS is used by Xen IIRC and they don't want to build in the
whole hibernation image creation etc code (which they never use anyway).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at