All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.