public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: linux-pm@lists.osdl.org
Subject: Re: Runtime device power management in userspace
Date: Sat, 24 Dec 2005 01:40:30 +0100	[thread overview]
Message-ID: <20051224004029.GC16043@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.50.0512230706530.13289-100000@monsoon.he.net>

On Pá 23-12-05 07:12:35, Patrick Mochel wrote:
> On Fri, 23 Dec 2005, Holger Macht wrote:
> > We implemented device runtime power management in a userspace application
> > (the powersave daemon). In this specific case, it means to successively
> > put pci devices into D3 powersave mode with writing a numerical '3' to the
> > corresponding power state file.
> >
> > There are two main reasons for us to even doing this:
> >
> >   1. At first, the obvious reason. As mentioned in our research regarding
> >      power consumption on this list, there is a very huge potential to
> >      save battery power.
> >
> >   2. Due to the fact that this is AFAIK a heavily untested area, as a side
> >      effect, we like to get reports about broken modules/drivers and maybe
> >      get them fixed.
> 
> That's great!
> 
> Please note that D3 is only relevant for PCI devices and for ACPI devices.
> The fact that it's the same value for every device in the system is a
> design flaw. Please be aware that the value to write to the device file
> could change, and will be dependent on the type (bus) of device, and quite
> possibly on the device itself. It may not even be '3' for all PCI devices
> in the future, or may be a string rather than 1 character, or simply a '1'
> into a different file.

Is there enough locking in driver core to make this safe?

Ouch and BTW *right* value is _2_, today... because state_store() uses
value from user as a pm_message_t.event. We should at least supply
some hint that it is runtime suspend in pm_message_t.flags --
unfortunately we do not have pm_message_t.flags yet.

Something like this is needed -- userspace should not play with
pm_message_t.state directly. [not even compile tested, have to sleep.]

I guess we should also audit the drivers... It needs locking against
user supplying requests concurently.

> Also, is there source available?

Should be, we are trying to do *Open*SUSE these days ;-))).

								Pavel

diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -34,12 +34,14 @@ static ssize_t state_store(struct device
 {
 	pm_message_t state;
 	char * rest;
-	int error = 0;
+	int error = 0, i;
 
-	state.event = simple_strtoul(buf, &rest, 10);
+	i = simple_strtoul(buf, &rest, 10);
+	state.event = PM_EVENT_SUSPEND;
+	state.flags = PM_FLAGS_RUNTIME;
 	if (*rest)
 		return -EINVAL;
-	if (state.event)
+	if (i)
 		error = dpm_runtime_suspend(dev, state);
 	else
 		dpm_runtime_resume(dev);
diff --git a/include/linux/pm.h b/include/linux/pm.h
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -140,6 +140,7 @@ struct device;
 
 typedef struct pm_message {
 	int event;
+	int flags;
 } pm_message_t;
 
 /*
@@ -165,6 +166,8 @@ typedef struct pm_message {
 #define PM_EVENT_FREEZE 1
 #define PM_EVENT_SUSPEND 2
 
+#define PM_FLAGS_RUNTIME 1
+
 #define PMSG_FREEZE	((struct pm_message){ .event = PM_EVENT_FREEZE, })
 #define PMSG_SUSPEND	((struct pm_message){ .event = PM_EVENT_SUSPEND, })
 #define PMSG_ON		((struct pm_message){ .event = PM_EVENT_ON, })

-- 
Thanks, Sharp!

  reply	other threads:[~2005-12-24  0:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-23 14:30 Runtime device power management in userspace Holger Macht
2005-12-23 15:12 ` Patrick Mochel
2005-12-24  0:40   ` Pavel Machek [this message]
2005-12-26 20:43     ` Patrick Mochel
2005-12-26 22:33       ` Pavel Machek
2005-12-27 18:59         ` Patrick Mochel
2005-12-27 19:22           ` Pavel Machek
2005-12-27 19:29             ` Patrick Mochel
2005-12-27 19:41               ` Pavel Machek
2005-12-27 20:40                 ` Patrick Mochel
2005-12-27 21:06                   ` Pavel Machek
2005-12-26 22:47       ` Alan Stern
2005-12-27 17:29         ` Pavel Machek
2005-12-27 17:36           ` Randy.Dunlap
2005-12-24 15:31   ` Holger Macht
2005-12-26 20:58     ` Patrick Mochel
2005-12-27 20:04       ` Pavel Machek
2005-12-27 20:54         ` Patrick Mochel
2005-12-23 15:17 ` Alan Stern
2005-12-24  0:41   ` Pavel Machek
2005-12-24  0:43   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051224004029.GC16043@elf.ucw.cz \
    --to=pavel@suse.cz \
    --cc=linux-pm@lists.osdl.org \
    --cc=mochel@digitalimplant.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox