public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <ambx1@neo.rr.com>
To: linux-pm@lists.osdl.org
Subject: [RFC] Disabling Devices
Date: Sun, 8 May 2005 22:15:29 -0400	[thread overview]
Message-ID: <20050509021528.GB27448@neo.rr.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]


One potentially important aspect of power management is the ability for the
user to disable a device that he or she does not intend to use.  Our current
model does not allow for this.  Calling PMSG_SUSPEND won't cut it, because it
might enable wake events and is expecting the system to sleep.  It seems we
need to implement something specifically for this case.  Also, there is the
posibility of resource rebalancing, which requires yet another slightly
different behavior.

Consider if a user wanted to disable a pci bus...  If the bus was just
suspended, it would be straightforward, put all the children to sleep and
then turn off the bus.  However, in the case of disabling it (as in "do not
use me") all of the child devices would actually need to be unregistered.

Furthermore, take an ethernet controller as an example.  When suspending, just
run the driver specific logic.  When disabling, you actually want to unregister
from the net class interface.

Unbinding the driver may not be the solution, because the driver may be
retaining configuration state information lost during the power-down.

"Disabling" is just one possible user preference.  Selective-suspending a
device is another.  For example, if a user was using an ethernet interface on
a laptop, the wireless interface should probably reduce power consumption.
The kernel may be able to take care of this automatically via idle timers etc.

I'm interested in any opinions.  Should we try to support something like
this?  How might we go about it?

As another issue, how should we handle surprise removal between suspend and
resume?  It seems like we would need to tell the resume method about this.

Thanks,
Adam

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



             reply	other threads:[~2005-05-09  2:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09  2:15 Adam Belay [this message]
2005-05-09 10:46 ` [RFC] Disabling Devices Pavel Machek
2005-05-09 14:26 ` Alan Stern
2005-05-09 15:04   ` Adam Belay
2005-05-11  8:39     ` Pavel Machek
2005-05-09 16:57 ` David Brownell
     [not found] <Pine.LNX.4.44L0.0505091124370.5325-100000@iolanthe.rowland.org>
2005-05-09 16:51 ` David Brownell
2005-05-09 18:06   ` Alan Stern
2005-05-11 14:04     ` David Brownell
2005-05-11 19:10       ` Alan Stern
2005-05-13  7:30         ` David Brownell
2005-05-13 15:40           ` Alan Stern

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=20050509021528.GB27448@neo.rr.com \
    --to=ambx1@neo.rr.com \
    --cc=linux-pm@lists.osdl.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