All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.