From: Scott Wood <scottwood@freescale.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>,
Pavel Machek <pavel@ucw.cz>, Greg KH <greg@kroah.com>,
linux1394-devel@lists.sourceforge.net
Subject: Re: pci_set_power_state() failure and breaking suspend
Date: Tue, 24 Oct 2006 11:09:16 -0500 [thread overview]
Message-ID: <453E3AAC.9040403@freescale.com> (raw)
In-Reply-To: <200610241400.06047.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Tuesday, 24 October 2006 08:54, Benjamin Herrenschmidt wrote:
>>However, this raises the question of do we actually want to prevent
>>machines to suspend when they have a PCI device that don't have the PCI
>>PM capability ? I'm asking that because I can easily imagine that sort
>>of construct growing into more drivers (sounds logical if you don't
>>think) and I can even imagine somebody thinking it's a good idea to slap
>>a __must_check on pci_set_power_state() ...
>
>
> As far as the suspend to RAM is concerned, I don't know.
>
> For the suspend to disk we can ignore the error if we know that the device
> in question won't do anything like a DMA transfer into memory while we're
> creating the suspend image.
I think it should be ignored for suspend-to-RAM as well; even if a
device or two is consuming unnecessary power, it's better than not being
able to suspend at all, causing more things to consume unnecessary power.
At most, a warning should be issued so the user knows what's going on,
and can choose whether to suspend to disk instead (or choose to complain
to the device manufacturer).
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>,
linux1394-devel@lists.sourceforge.net,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Pavel Machek <pavel@ucw.cz>, Greg KH <greg@kroah.com>
Subject: Re: pci_set_power_state() failure and breaking suspend
Date: Tue, 24 Oct 2006 11:09:16 -0500 [thread overview]
Message-ID: <453E3AAC.9040403@freescale.com> (raw)
In-Reply-To: <200610241400.06047.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Tuesday, 24 October 2006 08:54, Benjamin Herrenschmidt wrote:
>>However, this raises the question of do we actually want to prevent
>>machines to suspend when they have a PCI device that don't have the PCI
>>PM capability ? I'm asking that because I can easily imagine that sort
>>of construct growing into more drivers (sounds logical if you don't
>>think) and I can even imagine somebody thinking it's a good idea to slap
>>a __must_check on pci_set_power_state() ...
>
>
> As far as the suspend to RAM is concerned, I don't know.
>
> For the suspend to disk we can ignore the error if we know that the device
> in question won't do anything like a DMA transfer into memory while we're
> creating the suspend image.
I think it should be ignored for suspend-to-RAM as well; even if a
device or two is consuming unnecessary power, it's better than not being
able to suspend at all, causing more things to consume unnecessary power.
At most, a warning should be issued so the user knows what's going on,
and can choose whether to suspend to disk instead (or choose to complain
to the device manufacturer).
-Scott
next prev parent reply other threads:[~2006-10-24 16:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-24 6:54 pci_set_power_state() failure and breaking suspend Benjamin Herrenschmidt
2006-10-24 7:40 ` Benjamin Herrenschmidt
2006-10-24 8:13 ` Stefan Richter
2006-10-24 8:13 ` Stefan Richter
2006-10-24 8:29 ` Benjamin Herrenschmidt
2006-10-24 8:29 ` Benjamin Herrenschmidt
2006-10-24 11:41 ` Stefan Richter
2006-10-24 11:41 ` Stefan Richter
2006-10-24 22:40 ` Benjamin Herrenschmidt
2006-10-25 6:40 ` Stefan Richter
2006-10-25 6:40 ` Stefan Richter
2006-10-25 6:48 ` Stefan Richter
2006-10-25 6:48 ` Stefan Richter
2006-10-25 6:51 ` Stefan Richter
2006-10-25 6:51 ` Stefan Richter
2006-10-25 7:44 ` [rfc patch linux1394-2.6.git 1/2] ieee1394: ohci1394: revert fail on error in suspend Stefan Richter
2006-10-25 7:46 ` [rfc patch linux1394-2.6.git 2/2] ieee1394: ohci1394: proper log messages in suspend and resume Stefan Richter
2006-10-24 12:00 ` pci_set_power_state() failure and breaking suspend Rafael J. Wysocki
2006-10-24 12:00 ` Rafael J. Wysocki
2006-10-24 16:09 ` Scott Wood [this message]
2006-10-24 16:09 ` Scott Wood
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=453E3AAC.9040403@freescale.com \
--to=scottwood@freescale.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=linuxppc-dev@ozlabs.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
/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.