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.wyso...@intel.com> > > > > 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?
Yes. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > > --- > > > > 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. > > config SUSPEND_FREEZER > 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. :-) > config HIBERNATE_CALLBACKS > 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). Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
