public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Andrew Morton <akpm@osdl.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Pierre Ossman <drzeus@drzeus.cx>, Pavel Machek <pavel@suse.cz>,
	Ondrej Zary <linux@rainbow-software.org>,
	Jaroslav Kysela <perex@perex.cz>,
	ALSA development <alsa-devel@alsa-project.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Takashi Iwai <tiwai@suse.de>,
	linux-pm@lists.linux-foundation.org
Subject: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards
Date: Sat, 12 Jan 2008 21:08:01 +0100	[thread overview]
Message-ID: <47891E21.8060209@keyaccess.nl> (raw)
In-Reply-To: <200801122008.10313.rjw@sisk.pl>

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

Hi Andrew.

pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm 
breaks resuming isapnp cards from hibernation. They need the pnp_start_dev 
to enable the device again after hibernation.

They don't really need the pnp_stop_dev() which the above mentioned patch 
also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() 
should also stay. Bjorn Helgaas should decide  -- currently the patch as you 
have it breaks drivers though. Could you drop it?

Then, if so and after you do that, could you apply the attached? That's also 
needed to resume (ALSA) ISA-PnP cards from hibernation due to the 
RES_DO_NOT_CHANGE test triggering for ALSA drivers and the pnp_start_dev() 
still not happening. More in the changelog...

On 12-01-08 20:08, Rafael J. Wysocki wrote:

> On Saturday, 12 of January 2008, Rene Herman wrote:

>> It seems all PnP drivers would need to stick a pnp_start_dev in their resume 
>> method
> 
> Yes.
> 
>> then which means it really belongs in core.
> 
> Yes, if practical.
> 
>> One important point where PnP and PCI differ is that PnP allows to change the
>> resources on a protocol level and I don't see how it could ever not be
>> necessary to restore the state a user may have set if power has been
>> removed. Hibernate is just that, isn't it?
> 
> Basically, yes, it is.

Rene.


[-- Attachment #2: pnp_driver_res_do_not_test.diff --]
[-- Type: text/plain, Size: 2275 bytes --]

commit 7d16e8b3e7739599d32c8006f9e84fadb86b8296
Author: Rene Herman <rene.herman@gmail.com>
Date:   Sat Jan 12 00:00:35 2008 +0100

    PNP: do not test PNP_DRIVER_RES_DO_NOT_CHANGE on suspend/resume
    
    The PNP_DRIVER_RES_DO_NOT_CHANGE flag is meant to signify that
    the PNP core should not change resources for the device -- not
    that it shouldn't disable/enable the device on suspend/resume.
    
    ALSA ISAPnP drivers set PNP_DRIVER_RES_DO_NOT_CHANAGE (0x0001)
    through setting PNP_DRIVER_RES_DISABLE (0x0003). The latter
    including the former may in itself be considered rather
    unexpected but doesn't change that suspend/resume wouldn't seem
    to have any business testing the flag.
    
    As reported by Ondrej Zary for snd-cs4236, ALSA driven ISAPnP
    cards don't survive swsusp hibernation with the resume skipping
    setting the resources due to testing the flag -- the same test
    in the suspend path isn't enough to keep hibernation from
    disabling the card it seems.
    
    These tests were added (in 2005) by Piere Ossman in commit
    68094e3251a664ee1389fcf179497237cbf78331, "alsa: Improved PnP
    suspend support" who doesn't remember why. This deletes them.
    
    Signed-off-by: Rene Herman <rene.herman@gmail.com>
    Tested-by: Ondrej Zary <linux@rainbow-software.org>

diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a262762..12a1645 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -161,8 +161,7 @@ static int pnp_bus_suspend(struct device *dev, pm_message_t state)
 			return error;
 	}
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
-	    pnp_can_disable(pnp_dev)) {
+	if (pnp_can_disable(pnp_dev)) {
 		error = pnp_stop_dev(pnp_dev);
 		if (error)
 			return error;
@@ -185,14 +184,17 @@ static int pnp_bus_resume(struct device *dev)
 	if (pnp_dev->protocol && pnp_dev->protocol->resume)
 		pnp_dev->protocol->resume(pnp_dev);
 
-	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
+	if (pnp_can_write(pnp_dev)) {
 		error = pnp_start_dev(pnp_dev);
 		if (error)
 			return error;
 	}
 
-	if (pnp_drv->resume)
-		return pnp_drv->resume(pnp_dev);
+	if (pnp_drv->resume) {
+		error = pnp_drv->resume(pnp_dev);
+		if (error)
+			return error;
+	}
 
 	return 0;
 }

  reply	other threads:[~2008-01-12 20:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09 22:43 PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236 Ondrej Zary
2008-01-10  1:53 ` [alsa-devel] " Rene Herman
2008-01-10  7:58   ` Jaroslav Kysela
2008-01-11  1:19     ` Rene Herman
2008-01-11  7:01       ` Pierre Ossman
2008-01-11 14:21         ` Rene Herman
2008-01-11 18:40           ` Ondrej Zary
2008-01-12  1:23             ` Rene Herman
2008-01-12 11:12               ` Pierre Ossman
2008-01-12 13:39                 ` Rene Herman
2008-01-12 15:21                   ` Pierre Ossman
2008-01-12 16:46                     ` Ondrej Zary
2008-01-12 17:00                     ` Rene Herman
2008-01-12 19:08                       ` Rafael J. Wysocki
2008-01-12 20:08                         ` Rene Herman [this message]
2008-01-13  5:50                           ` -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards Bjorn Helgaas
2008-01-13  6:13                             ` Rene Herman
2008-01-14 22:26                               ` Bjorn Helgaas
2008-01-14 23:46                                 ` Rene Herman
2008-01-15  7:51                                 ` Jaroslav Kysela
2008-01-16 17:46                                   ` Bjorn Helgaas
2008-01-16 18:03                                     ` Ondrej Zary
2008-01-16 18:16                                     ` Rene Herman
2008-01-12 19:01                   ` [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236 Rafael J. Wysocki

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=47891E21.8060209@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=akpm@osdl.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=drzeus@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=linux@rainbow-software.org \
    --cc=pavel@suse.cz \
    --cc=perex@perex.cz \
    --cc=rjw@sisk.pl \
    --cc=tiwai@suse.de \
    /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