linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	matthew@wil.cx,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-pm@lists.linux-foundation.org, drzeus@drzeus.cx,
	linux-acpi@vger.kernel.org, Adam Belay <ambx1@neo.rr.com>,
	Matthieu Castet <castet.matthieu@free.fr>,
	Li Shaohua <shaohua.li@intel.com>, Len Brown <lenb@kernel.org>
Subject: RFC: PNP: do not stop/start devices in suspend/resume path
Date: Wed, 5 Dec 2007 11:24:18 -0700	[thread overview]
Message-ID: <200712051124.18852.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <47514CE2.3000600@gmail.com>

Re: warning on suspend-to-RAM caused by
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
thread here: http://lkml.org/lkml/2007/11/22/110

On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote:
> I didn't get it. Maybe some trolls poking around or something (maybe the
> ext3 breakage which fsck fixed). It works after recompilation of the
> whole tree. And the important part -- the warning has gone.

Good.  It's not clear to me whether it is safe to leave devices
enabled while we sleep.  I don't see an actual problem, but there
might be something related to hotplug while we're asleep or something.
So I'll cc: some additional people who might have some insight.



RFC: PNP: do not stop/start devices in suspend/resume path

Do not disable PNP devices in the suspend path.  We still call
the driver's suspend method, which should prevent further use of
the device, and the protocol suspend method, which may put the
device in a low-power state.

This means we will not disable the device and release its
resources.  The driver suspend method typically does not release
its resources in the suspend path.  For example, if we have:

  03f8-03ff : 00:06
    03f8-03ff : serial

pnp_stop_dev() would release the 00:06 region, which still
has a child.  This causes a warning from __release_resource
and corrupts /proc/ioports.

However, we should do this the same way Windows does, so if
Windows disables devices before going to sleep, we should, too.
It doesn't *look* necessary to me because

  - In the ACPI 3.0b spec, I can't find any mention of _DIS in
    connection with sleep.  And Device Object Notifications,
    Section 5.6.3, Table 5-43, says we should get a bus check
    after awakening if hardware was removed while we slept.

    This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx
    makes a similar point about how the OS re-enumerates devices
    as a result of a power state change (3rd last paragraph of
    text).

  - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx
    suggests that Windows only stops a device to rebalance hardware
    resources.

[This should go before
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch
for best bisect-ability.]

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: linux-mm/drivers/pnp/driver.c
===================================================================
--- linux-mm.orig/drivers/pnp/driver.c	2007-11-30 13:58:25.000000000 -0700
+++ linux-mm/drivers/pnp/driver.c	2007-12-03 09:58:35.000000000 -0700
@@ -161,13 +161,6 @@
 			return error;
 	}
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
-	    pnp_can_disable(pnp_dev)) {
-		error = pnp_stop_dev(pnp_dev);
-		if (error)
-			return error;
-	}
-
 	if (pnp_dev->protocol && pnp_dev->protocol->suspend)
 		pnp_dev->protocol->suspend(pnp_dev, state);
 	return 0;
@@ -177,7 +170,6 @@
 {
 	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
 	struct pnp_driver *pnp_drv = pnp_dev->driver;
-	int error;
 
 	if (!pnp_drv)
 		return 0;
@@ -185,12 +177,6 @@
 	if (pnp_dev->protocol && pnp_dev->protocol->resume)
 		pnp_dev->protocol->resume(pnp_dev);
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
-		error = pnp_start_dev(pnp_dev);
-		if (error)
-			return error;
-	}
-
 	if (pnp_drv->resume)
 		return pnp_drv->resume(pnp_dev);
 

  reply	other threads:[~2007-12-05 18:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-22 21:41 WARNING: at kernel/resource.c:189 __release_resource Jiri Slaby
2007-11-27  6:05 ` Andrew Morton
2007-11-27 12:38   ` Matthew Wilcox
2007-11-29 23:40   ` Bjorn Helgaas
2007-11-30  0:42     ` Andrew Morton
2007-11-30 21:08       ` Bjorn Helgaas
2007-11-30 22:49         ` Jiri Slaby
2007-11-30 22:58           ` Bjorn Helgaas
2007-12-01  8:12             ` Jiri Slaby
2007-12-01 12:00               ` Jiri Slaby
2007-12-05 18:24                 ` Bjorn Helgaas [this message]
2007-12-05 18:50                   ` RFC: PNP: do not stop/start devices in suspend/resume path Matthew Wilcox
2007-12-06  1:07                   ` Rafael J. Wysocki
2007-12-06 23:25                   ` Bjorn Helgaas
2007-12-12  8:16                     ` Andrew Morton
2007-12-12 16:29                       ` Bjorn Helgaas
2007-12-13  8:26                     ` Pierre Ossman
2007-12-07  7:13                   ` RFC: " Shaohua Li
2007-12-10 23:26                     ` Bjorn Helgaas
2007-12-24  1:43                   ` do not stop/start devices in suspend/resume path: the SCSI case Stephane Ascoet
2007-12-24  3:21                     ` Bjorn Helgaas
2007-12-01 21:01     ` WARNING: at kernel/resource.c:189 __release_resource Pierre Ossman

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=200712051124.18852.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=ambx1@neo.rr.com \
    --cc=castet.matthieu@free.fr \
    --cc=drzeus@drzeus.cx \
    --cc=jirislaby@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=matthew@wil.cx \
    --cc=shaohua.li@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).