* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Ray Lee @ 2011-02-08 1:17 UTC (permalink / raw)
To: Mark Brown
Cc: Alan Stern, Stephen Rothwell, Geert Uytterhoeven,
Rafael J. Wysocki, Len Brown, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, ppc-dev
In-Reply-To: <20110207154953.GN10564@opensource.wolfsonmicro.com>
On Mon, Feb 7, 2011 at 7:49 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> I'm rather hoping that they'll notice the mailing list thread or that
> someone else who knows what's going on with them does
Surely you're joking. I mean, do _you_ scan every message that comes
through lkml and its various sister lists?
Do a git blame and add them to the CC:. It's the polite thing to do.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Dmitry Torokhov @ 2011-02-08 0:50 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mark Brown, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, linux-embedded, Ingo Molnar
In-Reply-To: <201102080005.40448.rjw@sisk.pl>
On Tue, Feb 08, 2011 at 12:05:40AM +0100, Rafael J. Wysocki wrote:
> On Monday, February 07, 2011, Dmitry Torokhov wrote:
> > On Mon, Feb 07, 2011 at 11:00:03PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, February 07, 2011, Dmitry Torokhov wrote:
> > > > On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote:
> > > > > On Monday, February 07, 2011, Mark Brown wrote:
> > > > > >
> > > > > > Yeah, but some people seem very keen on removing the pointers to the PM
> > > > > > ops entirely when CONFIG_PM is disabled which means that you end up with
> > > > > > varying idioms for what you do with the PM ops as stuff gets ifdefed
> > > > > > out. Then again I'm not sure anything would make those people any
> > > > > > happier.
> > > > >
> > > > > I really think we should do things that makes sense rather that worry about
> > > > > who's going to like or dislike it (except for Linus maybe, but he tends to like
> > > > > things that make sense anyway). At this point I think the change I suggested
> > > > > makes sense, because it (a) simplifies things and (b) follows the quite common
> > > > > practice which is to make PM callbacks depend on CONFIG_PM.
> > > >
> > > > Many people make these callback dependent on PM not because it makes
> > > > much sense but because it is possible to do so. However, aside of
> > > > randconfig compile testing, nobody really tests drivers that implement
> > > > PM in the !CONFIG_PM setting.
> > >
> > > That I can agree with, but I'm not sure whether it is an argument against
> > > the patch I've just posted or for it?
> >
> > More of an observation for your (b) justification. I'd probably force
> > CONFIG_PM to always 'y'w while we weeding references to it from
> > drivers...
>
> We simply can't force CONFIG_PM to 'y', because some platforms want it to be 'n'.
>
Again, want or need? It would be nice to know answer to this question.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Rafael J. Wysocki @ 2011-02-07 23:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Len Brown, linux-embedded, Mark Brown, linux-kernel, Ingo Molnar,
linux-pm, Andrew Morton
In-Reply-To: <20110207222350.GA24804@core.coreip.homeip.net>
On Monday, February 07, 2011, Dmitry Torokhov wrote:
> On Mon, Feb 07, 2011 at 11:00:03PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 07, 2011, Dmitry Torokhov wrote:
> > > On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote:
> > > > On Monday, February 07, 2011, Mark Brown wrote:
> > > > >
> > > > > Yeah, but some people seem very keen on removing the pointers to the PM
> > > > > ops entirely when CONFIG_PM is disabled which means that you end up with
> > > > > varying idioms for what you do with the PM ops as stuff gets ifdefed
> > > > > out. Then again I'm not sure anything would make those people any
> > > > > happier.
> > > >
> > > > I really think we should do things that makes sense rather that worry about
> > > > who's going to like or dislike it (except for Linus maybe, but he tends to like
> > > > things that make sense anyway). At this point I think the change I suggested
> > > > makes sense, because it (a) simplifies things and (b) follows the quite common
> > > > practice which is to make PM callbacks depend on CONFIG_PM.
> > >
> > > Many people make these callback dependent on PM not because it makes
> > > much sense but because it is possible to do so. However, aside of
> > > randconfig compile testing, nobody really tests drivers that implement
> > > PM in the !CONFIG_PM setting.
> >
> > That I can agree with, but I'm not sure whether it is an argument against
> > the patch I've just posted or for it?
>
> More of an observation for your (b) justification. I'd probably force
> CONFIG_PM to always 'y'w while we weeding references to it from
> drivers...
We simply can't force CONFIG_PM to 'y', because some platforms want it to be 'n'.
OTOH, if CONFIG_PM = CONFIG_PM_SLEEP||CONFIG_PM_RUNTIME, we can just leave the
#ifdefs as they are and simply avoid adding new ones, or use CONFIG_PM for all
PM callbacks.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Dmitry Torokhov @ 2011-02-07 22:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mark Brown, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, linux-embedded, Ingo Molnar
In-Reply-To: <201102072300.03986.rjw@sisk.pl>
On Mon, Feb 07, 2011 at 11:00:03PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 07, 2011, Dmitry Torokhov wrote:
> > On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, February 07, 2011, Mark Brown wrote:
> > > >
> > > > Yeah, but some people seem very keen on removing the pointers to the PM
> > > > ops entirely when CONFIG_PM is disabled which means that you end up with
> > > > varying idioms for what you do with the PM ops as stuff gets ifdefed
> > > > out. Then again I'm not sure anything would make those people any
> > > > happier.
> > >
> > > I really think we should do things that makes sense rather that worry about
> > > who's going to like or dislike it (except for Linus maybe, but he tends to like
> > > things that make sense anyway). At this point I think the change I suggested
> > > makes sense, because it (a) simplifies things and (b) follows the quite common
> > > practice which is to make PM callbacks depend on CONFIG_PM.
> >
> > Many people make these callback dependent on PM not because it makes
> > much sense but because it is possible to do so. However, aside of
> > randconfig compile testing, nobody really tests drivers that implement
> > PM in the !CONFIG_PM setting.
>
> That I can agree with, but I'm not sure whether it is an argument against
> the patch I've just posted or for it?
More of an observation for your (b) justification. I'd probably force
CONFIG_PM to always 'y'w while we weeding references to it from
drivers...
--
Dmitry
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Rafael J. Wysocki @ 2011-02-07 22:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, linux-embedded, Ingo Molnar
In-Reply-To: <20110207214732.GA24703@core.coreip.homeip.net>
On Monday, February 07, 2011, Dmitry Torokhov wrote:
> On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 07, 2011, Mark Brown wrote:
> > >
> > > Yeah, but some people seem very keen on removing the pointers to the PM
> > > ops entirely when CONFIG_PM is disabled which means that you end up with
> > > varying idioms for what you do with the PM ops as stuff gets ifdefed
> > > out. Then again I'm not sure anything would make those people any
> > > happier.
> >
> > I really think we should do things that makes sense rather that worry about
> > who's going to like or dislike it (except for Linus maybe, but he tends to like
> > things that make sense anyway). At this point I think the change I suggested
> > makes sense, because it (a) simplifies things and (b) follows the quite common
> > practice which is to make PM callbacks depend on CONFIG_PM.
>
> Many people make these callback dependent on PM not because it makes
> much sense but because it is possible to do so. However, aside of
> randconfig compile testing, nobody really tests drivers that implement
> PM in the !CONFIG_PM setting.
That I can agree with, but I'm not sure whether it is an argument against
the patch I've just posted or for it?
Rafael
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Dmitry Torokhov @ 2011-02-07 21:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mark Brown, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, linux-embedded, Ingo Molnar
In-Reply-To: <201102072215.59921.rjw@sisk.pl>
On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 07, 2011, Mark Brown wrote:
> >
> > Yeah, but some people seem very keen on removing the pointers to the PM
> > ops entirely when CONFIG_PM is disabled which means that you end up with
> > varying idioms for what you do with the PM ops as stuff gets ifdefed
> > out. Then again I'm not sure anything would make those people any
> > happier.
>
> I really think we should do things that makes sense rather that worry about
> who's going to like or dislike it (except for Linus maybe, but he tends to like
> things that make sense anyway). At this point I think the change I suggested
> makes sense, because it (a) simplifies things and (b) follows the quite common
> practice which is to make PM callbacks depend on CONFIG_PM.
Many people make these callback dependent on PM not because it makes
much sense but because it is possible to do so. However, aside of
randconfig compile testing, nobody really tests drivers that implement
PM in the !CONFIG_PM setting.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Rafael J. Wysocki @ 2011-02-07 21:15 UTC (permalink / raw)
To: Mark Brown
Cc: Len Brown, Alan Stern, linux-pm, linux-kernel, Andrew Morton,
Dmitry Torokhov, linux-embedded, Ingo Molnar
In-Reply-To: <20110207201803.GU10564@opensource.wolfsonmicro.com>
On Monday, February 07, 2011, Mark Brown wrote:
> On Mon, Feb 07, 2011 at 08:46:48PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 07, 2011, Mark Brown wrote:
> > > On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote:
>
> > > > I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
>
> > > That still leaves the IA64 emulator to worry about
>
> > Why exactly?
>
> Actually not so much the IA64 emulator (which does have the !PM
> dependency declared already - I expect that'd just be moved) as any
> other platforms with an undeclared dependency on !PM.
If they depend on !PM, they cannot set PM_SLEEP or PM_RUNTIME, right?
So, if PM is defined as PM_SLEEP || PM_RUNTIME, everything should be fine
in that respect I suppose.
> > > but I'm not fundamentally opposed to that, it achieves a similar effect. The
> > > main thing I'm looking for here is to cut down on the configuration options
> > > we have to maintain.
>
> > But I must say you chose a particularly bad time for that from my point of view.
>
> This doesn't seem like it's a worse time than any other?
It is, because I'm working on some other changes right now that this interferes
with quite a bit. Whatever.
> > > > However, there's a number of things that I'm afraid wouldn't build correctly
> > > > if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.
>
> > > Actually CONFIG_PM_OPS probably also wants to be on independantly of
> > > those two sometimes for .poweroff() which I'd expect to run even if we
> > > can't suspend.
>
> > If you worry about that, then add CONFIG_PM_POWEROFF and make CONFIG_PM(_OPS)
> > depend on it, but I don't think it really is worth it, because people
> > generally don't make the poweroff code depend on CONFIG_PM.
>
> Yeah, but some people seem very keen on removing the pointers to the PM
> ops entirely when CONFIG_PM is disabled which means that you end up with
> varying idioms for what you do with the PM ops as stuff gets ifdefed
> out. Then again I'm not sure anything would make those people any
> happier.
I really think we should do things that makes sense rather that worry about
who's going to like or dislike it (except for Linus maybe, but he tends to like
things that make sense anyway). At this point I think the change I suggested
makes sense, because it (a) simplifies things and (b) follows the quite common
practice which is to make PM callbacks depend on CONFIG_PM.
Anyway, below is a proof-of-concept patch. It builds for me with a few
different combinations of the relevant options, but YMMV. It probably
should be split into two or three patches for merging, but I guess a single
patch is better for testing. Please let me know if there are any problems
with it.
I'd appreciate it if people could review/test it and drop their comments.
Thanks,
Rafael
---
arch/x86/xen/Kconfig | 2 +-
drivers/acpi/Kconfig | 1 -
drivers/acpi/bus.c | 4 +---
drivers/acpi/internal.h | 6 ++++++
drivers/acpi/sleep.c | 13 +++++++++++--
drivers/base/power/Makefile | 3 +--
drivers/net/e1000e/netdev.c | 8 ++++----
drivers/net/pch_gbe/pch_gbe_main.c | 2 +-
drivers/pci/pci-driver.c | 4 ++--
drivers/scsi/Makefile | 2 +-
drivers/scsi/scsi_priv.h | 2 +-
drivers/scsi/scsi_sysfs.c | 2 +-
drivers/usb/core/hcd-pci.c | 4 ++--
include/acpi/acpi_bus.h | 2 +-
include/linux/pm.h | 2 +-
kernel/power/Kconfig | 29 +++--------------------------
16 files changed, 37 insertions(+), 49 deletions(-)
Index: linux-2.6/kernel/power/Kconfig
===================================================================
--- linux-2.6.orig/kernel/power/Kconfig
+++ linux-2.6/kernel/power/Kconfig
@@ -1,24 +1,3 @@
-config PM
- bool "Power Management support"
- depends on !IA64_HP_SIM
- ---help---
- "Power Management" means that parts of your computer are shut
- off or put into a power conserving "sleep" mode if they are not
- being used. There are two competing standards for doing this: APM
- and ACPI. If you want to use either one, say Y here and then also
- to the requisite support below.
-
- Power Management is most important for battery powered laptop
- computers; if you have a laptop, check out the Linux Laptop home
- page on the WWW at <http://www.linux-on-laptops.com/> or
- Tuxmobil - Linux on Mobile Computers at <http://www.tuxmobil.org/>
- and the Battery Powered Linux mini-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- Note that, even if you say N here, Linux on the x86 architecture
- will issue the hlt instruction if nothing is to be done, thereby
- sending the processor to sleep and saving power.
-
config PM_DEBUG
bool "Power Management Debug Support"
depends on PM
@@ -102,7 +81,7 @@ config PM_SLEEP_ADVANCED_DEBUG
config SUSPEND
bool "Suspend to RAM and standby"
- depends on PM && ARCH_SUSPEND_POSSIBLE
+ depends on ARCH_SUSPEND_POSSIBLE
default y
---help---
Allow the system to enter sleep states in which main memory is
@@ -133,7 +112,7 @@ config SUSPEND_FREEZER
config HIBERNATION
bool "Hibernation (aka 'suspend to disk')"
- depends on PM && SWAP && ARCH_HIBERNATION_POSSIBLE
+ depends on SWAP && ARCH_HIBERNATION_POSSIBLE
select LZO_COMPRESS
select LZO_DECOMPRESS
---help---
@@ -224,7 +203,6 @@ config APM_EMULATION
config PM_RUNTIME
bool "Run-time PM core functionality"
- depends on PM
---help---
Enable functionality allowing I/O devices to be put into energy-saving
(low power) states at run time (or autosuspended) after a specified
@@ -236,7 +214,7 @@ config PM_RUNTIME
responsible for the actual handling of the autosuspend requests and
wake-up events.
-config PM_OPS
+config PM
bool
depends on PM_SLEEP || PM_RUNTIME
default y
@@ -246,7 +224,6 @@ config ARCH_HAS_OPP
config PM_OPP
bool "Operating Performance Point (OPP) Layer library"
- depends on PM
depends on ARCH_HAS_OPP
---help---
SOCs have a standard set of tuples consisting of frequency and
Index: linux-2.6/drivers/acpi/Kconfig
===================================================================
--- linux-2.6.orig/drivers/acpi/Kconfig
+++ linux-2.6/drivers/acpi/Kconfig
@@ -7,7 +7,6 @@ menuconfig ACPI
depends on !IA64_HP_SIM
depends on IA64 || X86
depends on PCI
- depends on PM
select PNP
default y
help
Index: linux-2.6/arch/x86/xen/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/xen/Kconfig
+++ linux-2.6/arch/x86/xen/Kconfig
@@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY
config XEN_SAVE_RESTORE
bool
- depends on XEN && PM
+ depends on XEN
default y
config XEN_DEBUG_FS
Index: linux-2.6/drivers/net/e1000e/netdev.c
===================================================================
--- linux-2.6.orig/drivers/net/e1000e/netdev.c
+++ linux-2.6/drivers/net/e1000e/netdev.c
@@ -5307,7 +5307,7 @@ void e1000e_disable_aspm(struct pci_dev
__e1000e_disable_aspm(pdev, state);
}
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
static bool e1000e_pm_ready(struct e1000_adapter *adapter)
{
return !!adapter->tx_ring->buffer_info;
@@ -5458,7 +5458,7 @@ static int e1000_runtime_resume(struct d
return __e1000_resume(pdev);
}
#endif /* CONFIG_PM_RUNTIME */
-#endif /* CONFIG_PM_OPS */
+#endif /* CONFIG_PM */
static void e1000_shutdown(struct pci_dev *pdev)
{
@@ -6164,7 +6164,7 @@ static DEFINE_PCI_DEVICE_TABLE(e1000_pci
};
MODULE_DEVICE_TABLE(pci, e1000_pci_tbl);
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
static const struct dev_pm_ops e1000_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(e1000_suspend, e1000_resume)
SET_RUNTIME_PM_OPS(e1000_runtime_suspend,
@@ -6178,7 +6178,7 @@ static struct pci_driver e1000_driver =
.id_table = e1000_pci_tbl,
.probe = e1000_probe,
.remove = __devexit_p(e1000_remove),
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
.driver.pm = &e1000_pm_ops,
#endif
.shutdown = e1000_shutdown,
Index: linux-2.6/drivers/acpi/sleep.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep.c
+++ linux-2.6/drivers/acpi/sleep.c
@@ -567,7 +567,7 @@ int acpi_suspend(u32 acpi_state)
return -EINVAL;
}
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
/**
* acpi_pm_device_sleep_state - return preferred power state of ACPI device
* in the system sleep state given by %acpi_target_sleep_state
@@ -653,9 +653,18 @@ int acpi_pm_device_sleep_state(struct de
*d_min_p = d_min;
return d_max;
}
-#endif /* CONFIG_PM_OPS */
+#endif /* CONFIG_PM */
#ifdef CONFIG_PM_SLEEP
+bool acpi_set_pm_flag(void)
+{
+ if (!(pm_flags & PM_APM)) {
+ pm_flags |= PM_ACPI;
+ return true;
+ }
+ return false;
+}
+
/**
* acpi_pm_device_sleep_wake - enable or disable the system wake-up
* capability of given device
Index: linux-2.6/drivers/base/power/Makefile
===================================================================
--- linux-2.6.orig/drivers/base/power/Makefile
+++ linux-2.6/drivers/base/power/Makefile
@@ -1,7 +1,6 @@
-obj-$(CONFIG_PM) += sysfs.o
+obj-$(CONFIG_PM) += sysfs.o generic_ops.o
obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o
obj-$(CONFIG_PM_RUNTIME) += runtime.o
-obj-$(CONFIG_PM_OPS) += generic_ops.o
obj-$(CONFIG_PM_TRACE_RTC) += trace.o
obj-$(CONFIG_PM_OPP) += opp.o
Index: linux-2.6/drivers/scsi/scsi_priv.h
===================================================================
--- linux-2.6.orig/drivers/scsi/scsi_priv.h
+++ linux-2.6/drivers/scsi/scsi_priv.h
@@ -146,7 +146,7 @@ static inline void scsi_netlink_exit(voi
#endif
/* scsi_pm.c */
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
extern const struct dev_pm_ops scsi_bus_pm_ops;
#endif
#ifdef CONFIG_PM_RUNTIME
Index: linux-2.6/drivers/scsi/Makefile
===================================================================
--- linux-2.6.orig/drivers/scsi/Makefile
+++ linux-2.6/drivers/scsi/Makefile
@@ -165,7 +165,7 @@ scsi_mod-$(CONFIG_SCSI_NETLINK) += scsi_
scsi_mod-$(CONFIG_SYSCTL) += scsi_sysctl.o
scsi_mod-$(CONFIG_SCSI_PROC_FS) += scsi_proc.o
scsi_mod-y += scsi_trace.o
-scsi_mod-$(CONFIG_PM_OPS) += scsi_pm.o
+scsi_mod-$(CONFIG_PM) += scsi_pm.o
scsi_tgt-y += scsi_tgt_lib.o scsi_tgt_if.o
Index: linux-2.6/drivers/scsi/scsi_sysfs.c
===================================================================
--- linux-2.6.orig/drivers/scsi/scsi_sysfs.c
+++ linux-2.6/drivers/scsi/scsi_sysfs.c
@@ -383,7 +383,7 @@ struct bus_type scsi_bus_type = {
.name = "scsi",
.match = scsi_bus_match,
.uevent = scsi_bus_uevent,
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
.pm = &scsi_bus_pm_ops,
#endif
};
Index: linux-2.6/drivers/usb/core/hcd-pci.c
===================================================================
--- linux-2.6.orig/drivers/usb/core/hcd-pci.c
+++ linux-2.6/drivers/usb/core/hcd-pci.c
@@ -335,7 +335,7 @@ void usb_hcd_pci_shutdown(struct pci_dev
}
EXPORT_SYMBOL_GPL(usb_hcd_pci_shutdown);
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
#ifdef CONFIG_PPC_PMAC
static void powermac_set_asic(struct pci_dev *pci_dev, int enable)
@@ -580,4 +580,4 @@ const struct dev_pm_ops usb_hcd_pci_pm_o
};
EXPORT_SYMBOL_GPL(usb_hcd_pci_pm_ops);
-#endif /* CONFIG_PM_OPS */
+#endif /* CONFIG_PM */
Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -431,7 +431,7 @@ static void pci_device_shutdown(struct d
pci_msix_shutdown(pci_dev);
}
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
/* Auxiliary functions used for system resume and run-time resume. */
@@ -1059,7 +1059,7 @@ static int pci_pm_runtime_idle(struct de
#endif /* !CONFIG_PM_RUNTIME */
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
const struct dev_pm_ops pci_dev_pm_ops = {
.prepare = pci_pm_prepare,
Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -380,7 +380,7 @@ struct acpi_pci_root *acpi_pci_find_root
int acpi_enable_wakeup_device_power(struct acpi_device *dev, int state);
int acpi_disable_wakeup_device_power(struct acpi_device *dev);
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
int acpi_pm_device_sleep_state(struct device *, int *);
#else
static inline int acpi_pm_device_sleep_state(struct device *d, int *p)
Index: linux-2.6/include/linux/pm.h
===================================================================
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -267,7 +267,7 @@ const struct dev_pm_ops name = { \
* callbacks provided by device drivers supporting both the system sleep PM and
* runtime PM, make the pm member point to generic_subsys_pm_ops.
*/
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
extern struct dev_pm_ops generic_subsys_pm_ops;
#define GENERIC_SUBSYS_PM_OPS (&generic_subsys_pm_ops)
#else
Index: linux-2.6/drivers/acpi/bus.c
===================================================================
--- linux-2.6.orig/drivers/acpi/bus.c
+++ linux-2.6/drivers/acpi/bus.c
@@ -1025,9 +1025,7 @@ static int __init acpi_init(void)
if (!result) {
pci_mmcfg_late_init();
- if (!(pm_flags & PM_APM))
- pm_flags |= PM_ACPI;
- else {
+ if (!acpi_set_pm_flag()) {
printk(KERN_INFO PREFIX
"APM is already active, exiting\n");
disable_acpi();
Index: linux-2.6/drivers/acpi/internal.h
===================================================================
--- linux-2.6.orig/drivers/acpi/internal.h
+++ linux-2.6/drivers/acpi/internal.h
@@ -82,12 +82,18 @@ void acpi_ec_unblock_transactions_early(
extern int acpi_sleep_init(void);
#ifdef CONFIG_ACPI_SLEEP
+/* drivers/acpi/sleep.c */
+bool acpi_set_pm_flag(void);
+
+/* drivers/acpi/nvs.c */
int acpi_sleep_proc_init(void);
int suspend_nvs_alloc(void);
void suspend_nvs_free(void);
int suspend_nvs_save(void);
void suspend_nvs_restore(void);
#else
+static inline bool acpi_set_pm_flag(void) { return true; }
+
static inline int acpi_sleep_proc_init(void) { return 0; }
static inline int suspend_nvs_alloc(void) { return 0; }
static inline void suspend_nvs_free(void) {}
Index: linux-2.6/drivers/net/pch_gbe/pch_gbe_main.c
===================================================================
--- linux-2.6.orig/drivers/net/pch_gbe/pch_gbe_main.c
+++ linux-2.6/drivers/net/pch_gbe/pch_gbe_main.c
@@ -2430,7 +2430,7 @@ static struct pci_driver pch_gbe_pcidev
.id_table = pch_gbe_pcidev_id,
.probe = pch_gbe_probe,
.remove = pch_gbe_remove,
-#ifdef CONFIG_PM_OPS
+#ifdef CONFIG_PM
.driver.pm = &pch_gbe_pm_ops,
#endif
.shutdown = pch_gbe_shutdown,
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 20:18 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Alan Stern, linux-pm, linux-kernel, Andrew Morton,
Dmitry Torokhov, linux-embedded, Ingo Molnar
In-Reply-To: <201102072046.48763.rjw@sisk.pl>
On Mon, Feb 07, 2011 at 08:46:48PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 07, 2011, Mark Brown wrote:
> > On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote:
> > > I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
> > That still leaves the IA64 emulator to worry about
> Why exactly?
Actually not so much the IA64 emulator (which does have the !PM
dependency declared already - I expect that'd just be moved) as any
other platforms with an undeclared dependency on !PM.
> > but I'm not fundamentally opposed to that, it achieves a similar effect. The
> > main thing I'm looking for here is to cut down on the configuration options
> > we have to maintain.
> But I must say you chose a particularly bad time for that from my point of view.
This doesn't seem like it's a worse time than any other?
> > > However, there's a number of things that I'm afraid wouldn't build correctly
> > > if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.
> > Actually CONFIG_PM_OPS probably also wants to be on independantly of
> > those two sometimes for .poweroff() which I'd expect to run even if we
> > can't suspend.
> If you worry about that, then add CONFIG_PM_POWEROFF and make CONFIG_PM(_OPS)
> depend on it, but I don't think it really is worth it, because people
> generally don't make the poweroff code depend on CONFIG_PM.
Yeah, but some people seem very keen on removing the pointers to the PM
ops entirely when CONFIG_PM is disabled which means that you end up with
varying idioms for what you do with the PM ops as stuff gets ifdefed
out. Then again I'm not sure anything would make those people any
happier.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Rafael J. Wysocki @ 2011-02-07 19:46 UTC (permalink / raw)
To: Mark Brown
Cc: Len Brown, Alan Stern, linux-pm, linux-kernel, Andrew Morton,
Dmitry Torokhov, linux-embedded, Ingo Molnar
In-Reply-To: <20110207193026.GT10564@opensource.wolfsonmicro.com>
On Monday, February 07, 2011, Mark Brown wrote:
> On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 07, 2011, Mark Brown wrote:
>
> > > config PM_DEBUG
> > > bool "Power Management Debug Support"
>
> > I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
>
> That still leaves the IA64 emulator to worry about
Why exactly?
> but I'm not fundamentally opposed to that, it achieves a similar effect. The
> main thing I'm looking for here is to cut down on the configuration options
> we have to maintain.
But I must say you chose a particularly bad time for that from my point of view.
> > However, there's a number of things that I'm afraid wouldn't build correctly
> > if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.
>
> Actually CONFIG_PM_OPS probably also wants to be on independantly of
> those two sometimes for .poweroff() which I'd expect to run even if we
> can't suspend.
If you worry about that, then add CONFIG_PM_POWEROFF and make CONFIG_PM(_OPS)
depend on it, but I don't think it really is worth it, because people
generally don't make the poweroff code depend on CONFIG_PM.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Joe Perches @ 2011-02-07 19:33 UTC (permalink / raw)
To: Andrew Murray
Cc: Wolfram Sang, Geert Uytterhoeven, linux-embedded, linux kernel,
trivial, rdunlap
In-Reply-To: <AANLkTi=zbmf6QQ2qgv6jf_SJ_GwF=8XPW4CCs-9AJ16B@mail.gmail.com>
On Mon, 2011-02-07 at 18:12 +0000, Andrew Murray wrote:
> On 7 February 2011 09:29, Wolfram Sang <w.sang@pengutronix.de> wrote:
> > On Sun, Feb 06, 2011 at 04:23:09PM +0000, Andrew Murray wrote:
> >> +
> >> + For printing kernel pointers which should be hidden from unprivileged
> >> + users. The behaviour of %pK depends on the kptr_resrict sysctl - see
> >
> > Typo: Should be kptr_restrict.
> Updated patch:
trivia:
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
[]
> +Kernel Pointers:
> +
> + %pK 0x0
Bad example, leading zeros are emitted.
%pK 0x01234567 or 0x01234567890abcdef
depending on 32/64 bit. For 2.6.38, output should be 0x00000000
for a 0 if kptr_restrict is set, "(null)" or value otherwise.
> + For printing kernel pointers which should be hidden from unprivileged
> + users. The behaviour of %pK depends on the kptr_restrict sysctl - see
> + Documentation/sysctl/kernel.txt for more details.
> +
> +Struct Resources:
> +
> + %pr [mem 0x60000000-0x6fffffff flags 0x2200]
> + %pR [mem 0x60000000-0x6fffffff pref]
> +
> + For printing struct resources. The 'R' and 'r' specifiers result in a
> + printed resource with ('R') or without ('r') a decoded flags member.
Same issue, mem resources are printed using sizeof(resource_size_t) * 2
> +IPv6 addresses:
> +
> + %pI6 0001:0002:0003:0004:0005:0006:0007:0008
> + %pi6 00010002000300040005000600070008
> + %pI6c 1:2:3:4:5:6:7:8
> +
> + For printing IPv6 network-order 16 bit hex addresses. The 'I6' and 'i6'
> + specifiers result in a printed address with ('I6') or without ('i6')
> + colon-separators. Leading zeros are always used.
> +
> + The additional 'c' specifier can be used with the 'I' specifier to
> + print a compressed IPv6 address as described by
> + http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00.
It's probably better to use:
http://tools.ietf.org/html/rfc5952
> +
> +UUID/GUID addresses:
> +
> + %pU 00010203-0506-0708-090a-0b0c0d0e0fff
What happened to 04?
It's probably easier/simpler to just show all possible
output styles. Assuming an in memory incrementing
16 byte array, output is:
%pU 00010203-0405-0607-08090a0b0c0d0e0f
> + %pU[bBlL]
%pUb 00010203-0405-0607-08090a0b0c0d0e0f
%pUB 00010203-0405-0607-08090A0B0C0D0E0F
%pUl 03020100-0504-0706-08090a0b0c0d0e0f
%pUL 03020100-0504-0706-08090A0B0E0D0E0F
> + For printing 16 byte UUID/GUIDs addresses. The additional 'l', 'L',
> + 'b' and 'B' specifiers are used to specify a little endian order in
> + lower ('l') or upper case ('L') hex characters - and big endian order
> + in lower ('b') or upper case ('B') hex characters.
> +
> + Where no additional specifiers are used the default little endian
> + order with lower case hex characters will be printed.
> +
> +struct va_format:
> +
> + %pV
> +
> + For printing struct va_format structures. These contain a format string
> + and va_list as follows:
> +
> + struct va_format {
> + const char *fmt;
> + va_lost *va;
va_list
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 19:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Alan Stern, linux-pm, linux-kernel, Andrew Morton,
Dmitry Torokhov, linux-embedded, Ingo Molnar
In-Reply-To: <201102072014.04259.rjw@sisk.pl>
On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 07, 2011, Mark Brown wrote:
> > config PM_DEBUG
> > bool "Power Management Debug Support"
> I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
That still leaves the IA64 emulator to worry about but I'm not
fundamentally opposed to that, it achieves a similar effect. The main
thing I'm looking for here is to cut down on the configuration options
we have to maintain.
> However, there's a number of things that I'm afraid wouldn't build correctly
> if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.
Actually CONFIG_PM_OPS probably also wants to be on independantly of
those two sometimes for .poweroff() which I'd expect to run even if we
can't suspend.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Rafael J. Wysocki @ 2011-02-07 19:16 UTC (permalink / raw)
To: Mark Brown
Cc: Alan Stern, Stephen Rothwell, Geert Uytterhoeven, Len Brown,
linux-pm, linux-kernel, Andrew Morton, Dmitry Torokhov,
linux-embedded, ppc-dev
In-Reply-To: <20110207154953.GN10564@opensource.wolfsonmicro.com>
On Monday, February 07, 2011, Mark Brown wrote:
> On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote:
> > On Mon, 7 Feb 2011, Mark Brown wrote:
>
> > > I'd not be so sure - since it's a bool without an explicit default set
> > > Kconfig will default to disabling it and if anything enabling it is the
> > > option that requires special effort.
>
> > This may be a naive suggestion, but have you considered simply _asking_
> > the people who added those defconfigs?
>
> I'm rather hoping that they'll notice the mailing list thread or that
> someone else who knows what's going on with them does - as Geert pointed
> out there's a considerable number of defconfigs that have this turned
> off. It seems more sensible to get some idea if this seems sane to
> people in the general case before going trying to identify and contact
> so many individuals.
>
> If there are systems that really require disabling CONFIG_PM we probably
> need to add stuff to Kconfig to make sure it can't be enabled anyway;
> this shouldn't enable any new configurations.
Well, as I've just said, I don't like this change. I'd very much prefer it if
CONFIG_PM_OPS were renamed to CONFIG_PM.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Rafael J. Wysocki @ 2011-02-07 19:14 UTC (permalink / raw)
To: Mark Brown
Cc: Len Brown, Alan Stern, linux-pm, linux-kernel, Andrew Morton,
Dmitry Torokhov, linux-embedded, Ingo Molnar
In-Reply-To: <1297081335-13631-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Monday, February 07, 2011, Mark Brown wrote:
> It is very rare to find a current system which is both sufficiently
> resource constrained to want to compile out power management support
> and sufficiently power insensitive to be able to tolerate doing so.
> Since having the configuration option requires non-zero effort to
> maintain, with ifdefery in most drivers, but it is used with vanishing
> rarity it is simpler to just remove the option.
>
> Begin doing so by hiding it from users - this should attract complaints
> from any active users. The option is left disabled for the IA64 Ski
> simulator which is a partial simulator for IA64 systems mostly missing
> device support. This is a very limited use case which is unlikely to
> ever want to enable most drivers.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> kernel/power/Kconfig | 21 ++-------------------
> 1 files changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 2657299..99e3c52 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -1,23 +1,6 @@
> config PM
> - bool "Power Management support"
> - depends on !IA64_HP_SIM
> - ---help---
> - "Power Management" means that parts of your computer are shut
> - off or put into a power conserving "sleep" mode if they are not
> - being used. There are two competing standards for doing this: APM
> - and ACPI. If you want to use either one, say Y here and then also
> - to the requisite support below.
> -
> - Power Management is most important for battery powered laptop
> - computers; if you have a laptop, check out the Linux Laptop home
> - page on the WWW at <http://www.linux-on-laptops.com/> or
> - Tuxmobil - Linux on Mobile Computers at <http://www.tuxmobil.org/>
> - and the Battery Powered Linux mini-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - Note that, even if you say N here, Linux on the x86 architecture
> - will issue the hlt instruction if nothing is to be done, thereby
> - sending the processor to sleep and saving power.
> + bool
> + default y if !IA64_HP_SIM
>
> config PM_DEBUG
> bool "Power Management Debug Support"
I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
However, there's a number of things that I'm afraid wouldn't build correctly
if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.
Anyway, I'll try to prepare a patch doing that and see what happens.
Stay tuned.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-02-07 18:12 UTC (permalink / raw)
To: Wolfram Sang
Cc: Geert Uytterhoeven, linux-embedded, linux kernel, trivial,
rdunlap
In-Reply-To: <20110207092930.GA3123@pengutronix.de>
On 7 February 2011 09:29, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Sun, Feb 06, 2011 at 04:23:09PM +0000, Andrew Murray wrote:
>> +
>> + For printing kernel pointers which should be hidden from unprivileged
>> + users. The behaviour of %pK depends on the kptr_resrict sysctl - see
>
> Typo: Should be kptr_restrict.
Updated patch:
From: Andrew Murray <amurray@mpc-data.co.uk>
This patch updates the incomplete documentation concerning the printk
extended format specifiers.
Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
---
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 1b5a5dd..cad0dda 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -1,4 +1,4 @@
-If variable is of Type, use printk format specifier:
+f variable is of Type, use printk format specifier:
---------------------------------------------------------
int %d or %x
unsigned int %u or %x
@@ -9,7 +9,111 @@ If variable is of Type, use printk format specifier:
size_t %zu or %zx
ssize_t %zd or %zx
-Raw pointer value SHOULD be printed with %p.
+Raw pointer value SHOULD be printed with %p. The kernel supports
+the following extended format specifiers for pointer types:
+
+Symbols/Function Pointers:
+
+ %pF versatile_init+0x0/0x110
+ %pf versatile_init
+ %pS versatile_init+0x0/0x110
+ %ps versatile_init
+
+ For printing symbols and function pointers. The 'S' and 's' specifiers
+ result in the symbol name with ('S') or without ('s') offsets. Where
+ this is used on a kernel without KALLSYMS - the symbol address is
+ printed instead.
+
+ On ia64, ppc64 and parisc64 architectures function pointers are
+ actually function descriptors which must first be resolved. The 'F' and
+ 'f' specifiers perform this resolution and then provide the same
+ functionality as the 'S' and 's' specifiers.
+
+Kernel Pointers:
+
+ %pK 0x0
+
+ For printing kernel pointers which should be hidden from unprivileged
+ users. The behaviour of %pK depends on the kptr_restrict sysctl - see
+ Documentation/sysctl/kernel.txt for more details.
+
+Struct Resources:
+
+ %pr [mem 0x60000000-0x6fffffff flags 0x2200]
+ %pR [mem 0x60000000-0x6fffffff pref]
+
+ For printing struct resources. The 'R' and 'r' specifiers result in a
+ printed resource with ('R') or without ('r') a decoded flags member.
+
+MAC/FDDI addresses:
+
+ %pM 00:01:02:03:04:05
+ %pMF 00-01-02-03-04-05
+ %pm 000102030405
+
+ For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
+ specifiers result in a printed address with ('M') or without ('m') byte
+ separators. The default byte separator is the colon (':').
+
+ Where FDDI addresses are concerned the 'F' specifier can be used after
+ the 'M' specifier to use dash ('-') separators instead of the default
+ separator.
+
+IPv4 addresses:
+
+ %pI4 1.2.3.4
+ %pi4 001.002.003.004
+ %p[Ii][hnbl]
+
+ For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
+ specifiers result in a printed address with ('i4') or without ('I4')
+ leading zeros.
+
+ The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
+ host, network, big or little endian order addresses respectively. Where
+ no specifier is provided the default network/big endian order is used.
+
+IPv6 addresses:
+
+ %pI6 0001:0002:0003:0004:0005:0006:0007:0008
+ %pi6 00010002000300040005000600070008
+ %pI6c 1:2:3:4:5:6:7:8
+
+ For printing IPv6 network-order 16 bit hex addresses. The 'I6' and 'i6'
+ specifiers result in a printed address with ('I6') or without ('i6')
+ colon-separators. Leading zeros are always used.
+
+ The additional 'c' specifier can be used with the 'I' specifier to
+ print a compressed IPv6 address as described by
+ http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00.
+
+UUID/GUID addresses:
+
+ %pU 00010203-0506-0708-090a-0b0c0d0e0fff
+ %pU[bBlL]
+
+ For printing 16 byte UUID/GUIDs addresses. The additional 'l', 'L',
+ 'b' and 'B' specifiers are used to specify a little endian order in
+ lower ('l') or upper case ('L') hex characters - and big endian order
+ in lower ('b') or upper case ('B') hex characters.
+
+ Where no additional specifiers are used the default little endian
+ order with lower case hex characters will be printed.
+
+struct va_format:
+
+ %pV
+
+ For printing struct va_format structures. These contain a format string
+ and va_list as follows:
+
+ struct va_format {
+ const char *fmt;
+ va_lost *va;
+ };
+
+ Do not use this feature without some mechanism to verify the
+ correctness of the format string and va_list arguments.
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
@@ -32,4 +136,5 @@ Reminder: sizeof() result is of type size_t.
Thank you for your cooperation and attention.
-By Randy Dunlap <rdunlap@xenotime.net>
+By Randy Dunlap <rdunlap@xenotime.net> and
+Andrew Murray <amurray@mpc-data.co.uk>
^ permalink raw reply related
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 15:49 UTC (permalink / raw)
To: Alan Stern
Cc: Stephen Rothwell, Geert Uytterhoeven, Rafael J. Wysocki,
Len Brown, linux-pm, linux-kernel, Andrew Morton, Dmitry Torokhov,
linux-embedded, ppc-dev
In-Reply-To: <Pine.LNX.4.44L0.1102071035320.1924-100000@iolanthe.rowland.org>
On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote:
> On Mon, 7 Feb 2011, Mark Brown wrote:
> > I'd not be so sure - since it's a bool without an explicit default set
> > Kconfig will default to disabling it and if anything enabling it is the
> > option that requires special effort.
> This may be a naive suggestion, but have you considered simply _asking_
> the people who added those defconfigs?
I'm rather hoping that they'll notice the mailing list thread or that
someone else who knows what's going on with them does - as Geert pointed
out there's a considerable number of defconfigs that have this turned
off. It seems more sensible to get some idea if this seems sane to
people in the general case before going trying to identify and contact
so many individuals.
If there are systems that really require disabling CONFIG_PM we probably
need to add stuff to Kconfig to make sure it can't be enabled anyway;
this shouldn't enable any new configurations.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Alan Stern @ 2011-02-07 15:36 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Rothwell, Geert Uytterhoeven, Rafael J. Wysocki,
Len Brown, linux-pm, linux-kernel, Andrew Morton, Dmitry Torokhov,
linux-embedded, ppc-dev
In-Reply-To: <20110207152132.GM10564@opensource.wolfsonmicro.com>
On Mon, 7 Feb 2011, Mark Brown wrote:
> On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:
>
> > At least some of the powerpc defconfigs were added with CONFIG_PM
> > disabled. I assume that was on purpose (though it may not have been).
>
> I'd not be so sure - since it's a bool without an explicit default set
> Kconfig will default to disabling it and if anything enabling it is the
> option that requires special effort.
This may be a naive suggestion, but have you considered simply _asking_
the people who added those defconfigs?
Alan Stern
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 15:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Geert Uytterhoeven, Rafael J. Wysocki, Len Brown, Alan Stern,
linux-pm, linux-kernel, Andrew Morton, Dmitry Torokhov,
linux-embedded, ppc-dev
In-Reply-To: <20110208021916.68b33b37.sfr@canb.auug.org.au>
On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:
> At least some of the powerpc defconfigs were added with CONFIG_PM
> disabled. I assume that was on purpose (though it may not have been).
I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 15:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm,
linux-kernel, Andrew Morton, Dmitry Torokhov, linux-embedded,
ppc-dev
In-Reply-To: <20110208021045.699654ca.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Tue, 8 Feb 2011 02:10:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 7 Feb 2011 16:00:55 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > $ git grep "CONFIG_PM is not set"
> > 7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
> > 256
> > $
> >
> > 7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
> > savedefconfig, so that's a safe revision with untrimmed defconfigs.
>
> Yeah, but we can't tell if CONFIG_PM is turned off on purpose in those
> defconfigs, or just off because noone explicitly turned it on.
At least some of the powerpc defconfigs were added with CONFIG_PM
disabled. I assume that was on purpose (though it may not have been).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 15:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm,
linux-kernel, Andrew Morton, Dmitry Torokhov, linux-embedded,
ppc-dev
In-Reply-To: <AANLkTikw7j5Q7CGZK=Xbcgubt9LYBGiXf01wQ4nbg8NR@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
Hi Geert,
On Mon, 7 Feb 2011 16:00:55 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> $ git grep "CONFIG_PM is not set"
> 7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
> 256
> $
>
> 7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
> savedefconfig, so that's a safe revision with untrimmed defconfigs.
Yeah, but we can't tell if CONFIG_PM is turned off on purpose in those
defconfigs, or just off because noone explicitly turned it on.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Geert Uytterhoeven @ 2011-02-07 15:00 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Rothwell, linux-embedded, Len Brown, Dmitry Torokhov,
linux-kernel, Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev,
Andrew Morton
In-Reply-To: <20110207145031.GL10564@opensource.wolfsonmicro.com>
On Mon, Feb 7, 2011 at 15:50, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
>> On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
>> > Do you mean that these systems require CONFIG_PM be turned off, or just
>> > that people tend not to turn it on? If the latter would you expect any
>> > ill effects from doing so?
>
>> I don't know the answer to either question without testing. All I am
>> saying is that currently the default for CONFIG_PM is "off" and you are
>> changing it to be "on" and there may not have been any testing done of
>> that in some situations. We don't know where it was explicitly
>> turned off any more since we shrank our defconfig files (which was done
>> automatically) ... since it is off by default, it doesn't need to be
>> mentioned in a defconfig unless it needs to be turned on.
>
> My suspicion would be that it'll have been turned off by someone hitting
> return through a config upgrade rather than through deliberate effort.
> On the other hand if it is essential for some machines to have it
> disabled they probably want to have somethnig in Kconfig.
$ git grep "CONFIG_PM is not set"
7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
256
$
7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
savedefconfig, so that's a safe revision with untrimmed defconfigs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 14:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, ppc-dev
In-Reply-To: <20110208014432.2c9288e4.sfr@canb.auug.org.au>
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
> On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > Do you mean that these systems require CONFIG_PM be turned off, or just
> > that people tend not to turn it on? If the latter would you expect any
> > ill effects from doing so?
> I don't know the answer to either question without testing. All I am
> saying is that currently the default for CONFIG_PM is "off" and you are
> changing it to be "on" and there may not have been any testing done of
> that in some situations. We don't know where it was explicitly
> turned off any more since we shrank our defconfig files (which was done
> automatically) ... since it is off by default, it doesn't need to be
> mentioned in a defconfig unless it needs to be turned on.
My suspicion would be that it'll have been turned off by someone hitting
return through a config upgrade rather than through deliberate effort.
On the other hand if it is essential for some machines to have it
disabled they probably want to have somethnig in Kconfig.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 14:44 UTC (permalink / raw)
To: Mark Brown
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, ppc-dev
In-Reply-To: <20110207141829.GK10564@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Hi Mark,
On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:
> > On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> > > + bool
> > > + default y if !IA64_HP_SIM
>
> > Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
> > server configs), so this will unexpectedly turn it on for them.
>
> Do you mean that these systems require CONFIG_PM be turned off, or just
> that people tend not to turn it on? If the latter would you expect any
> ill effects from doing so?
I don't know the answer to either question without testing. All I am
saying is that currently the default for CONFIG_PM is "off" and you are
changing it to be "on" and there may not have been any testing done of
that in some situations. We don't know where it was explicitly
turned off any more since we shrank our defconfig files (which was done
automatically) ... since it is off by default, it doesn't need to be
mentioned in a defconfig unless it needs to be turned on.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 14:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, ppc-dev
In-Reply-To: <20110208011324.d5371c4c.sfr@canb.auug.org.au>
On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:
> On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > + bool
> > + default y if !IA64_HP_SIM
> Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
> server configs), so this will unexpectedly turn it on for them.
Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on? If the latter would you expect any
ill effects from doing so?
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Stephen Rothwell @ 2011-02-07 14:13 UTC (permalink / raw)
To: Mark Brown
Cc: Len Brown, linux-embedded, Dmitry Torokhov, linux-kernel,
Rafael J. Wysocki, Alan Stern, linux-pm, ppc-dev, Andrew Morton
In-Reply-To: <1297081335-13631-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1.1: Type: text/plain, Size: 1591 bytes --]
Hi Mark,
On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 2657299..99e3c52 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -1,23 +1,6 @@
> config PM
> - bool "Power Management support"
> - depends on !IA64_HP_SIM
> - ---help---
> - "Power Management" means that parts of your computer are shut
> - off or put into a power conserving "sleep" mode if they are not
> - being used. There are two competing standards for doing this: APM
> - and ACPI. If you want to use either one, say Y here and then also
> - to the requisite support below.
> -
> - Power Management is most important for battery powered laptop
> - computers; if you have a laptop, check out the Linux Laptop home
> - page on the WWW at <http://www.linux-on-laptops.com/> or
> - Tuxmobil - Linux on Mobile Computers at <http://www.tuxmobil.org/>
> - and the Battery Powered Linux mini-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - Note that, even if you say N here, Linux on the x86 architecture
> - will issue the hlt instruction if nothing is to be done, thereby
> - sending the processor to sleep and saving power.
> + bool
> + default y if !IA64_HP_SIM
Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
server configs), so this will unexpectedly turn it on for them.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 13:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, linux-arch
In-Reply-To: <AANLkTimxpRHW2TPwSnufpoeOHoEtkz1iaR3-VsC1qM4j@mail.gmail.com>
On Mon, Feb 07, 2011 at 01:40:28PM +0100, Geert Uytterhoeven wrote:
> Which means that (for now) I don't have to care that CONFIG_PM becomes
> unclearable. Other people may care, though...
The whole point of the patch is that (other than the IA64 emulator which
explicitly requires that CONFIG_PM be disabled) I strongly suspect that
nobody is actually using this configuration except as a result of
randconfig type testing.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox