mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@osdl.org>
Subject: [PATCH 2.6.9-rc1-bk] fix pci/pmcore enum value problem
Date: Wed, 8 Sep 2004 10:38:50 -0700	[thread overview]
Message-ID: <200409081038.50387.david-b@pacbell.net> (raw)

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

In contrast to previous versions of this patch, I've actually been using
this one ... it behaves OK with both /proc/sys/acpi and /sys/power/state,
at least in terms of letting drivers use pci_set_power_state() the same
way they've done since LK2.4 days.

- Dave

[-- Attachment #2: pmcore-0908.patch --]
[-- Type: text/x-diff, Size: 3217 bytes --]

Changes the PM_SUSPEND_MEM (and PM_SUSPEND_DISK) enum values so that
they make sense as PCI device power states.

(a) Fixes bugs whereby PCI drivers are being given bogus values.
    The should resolve OSDL bugid 2886 without changing the PCI
    API (its PM calls still act as on 2.4 kernels).

(b) Doesn't change the awkward assumption in the 2.6 PMcore that
    the /sys/bus/*/devices/power/state, /proc/acpi/sleep,
    dev->power.power_state, and dev->detach_state files share
    the same numeric codes ... even for busses very unlike PCI,
    or systems with several "on" policies as well as STD and STR.

Really we need to move away from "u32" codes that are easily confused
with each other, towards typed values (probably struct pointers), but
this is the simplest comprehensive fix for the PCI problem.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>


--- 1.16/include/linux/pm.h	Thu Jul  1 22:23:53 2004
+++ edited/include/linux/pm.h	Wed Sep  8 07:54:20 2004
@@ -194,11 +194,12 @@
 extern void (*pm_power_off)(void);
 
 enum {
-	PM_SUSPEND_ON,
-	PM_SUSPEND_STANDBY,
-	PM_SUSPEND_MEM,
-	PM_SUSPEND_DISK,
-	PM_SUSPEND_MAX,
+	PM_SUSPEND_ON = 0,
+	PM_SUSPEND_STANDBY = 1,
+	/* NOTE: PM_SUSPEND_MEM == PCI_D3hot */
+	PM_SUSPEND_MEM = 3,
+	PM_SUSPEND_DISK = 4,
+	PM_SUSPEND_MAX = 5,
 };
 
 enum {
--- 1.17/kernel/power/main.c	Mon Apr 12 10:54:21 2004
+++ edited/kernel/power/main.c	Wed Sep  8 07:54:20 2004
@@ -225,8 +225,8 @@
 	p = memchr(buf, '\n', n);
 	len = p ? p - buf : n;
 
-	for (s = &pm_states[state]; *s; s++, state++) {
-		if (!strncmp(buf, *s, len))
+	for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {
+		if (*s && !strncmp(buf, *s, len))
 			break;
 	}
 	if (*s)
--- 1.86/kernel/power/swsusp.c	Thu Jul  1 22:23:48 2004
+++ edited/kernel/power/swsusp.c	Wed Sep  8 07:54:20 2004
@@ -699,7 +699,7 @@
 	else
 #endif
 	{
-		device_suspend(3);
+		device_suspend(PM_SUSPEND_DISK);
 		device_shutdown();
 		machine_power_off();
 	}
@@ -720,7 +720,7 @@
 	mb();
 	spin_lock_irq(&suspend_pagedir_lock);	/* Done to disable interrupts */ 
 
-	device_power_down(3);
+	device_power_down(PM_SUSPEND_DISK);
 	PRINTK( "Waiting for DMAs to settle down...\n");
 	mdelay(1000);	/* We do not want some readahead with DMA to corrupt our memory, right?
 			   Do it with disabled interrupts for best effect. That way, if some
@@ -789,7 +789,7 @@
 {
 	int is_problem;
 	read_swapfiles();
-	device_power_down(3);
+	device_power_down(PM_SUSPEND_DISK);
 	is_problem = suspend_prepare_image();
 	device_power_up();
 	spin_unlock_irq(&suspend_pagedir_lock);
@@ -844,8 +844,8 @@
 		free_some_memory();
 		disable_nonboot_cpus();
 		/* Save state of all device drivers, and stop them. */
-		printk("Suspending devices... ");
-		if ((res = device_suspend(3))==0) {
+		printk("Suspending devices...\n");
+		if ((res = device_suspend(PM_SUSPEND_DISK))==0) {
 			/* If stopping device drivers worked, we proceed basically into
 			 * suspend_save_image.
 			 *
@@ -1200,7 +1200,7 @@
 		goto read_failure;
 	/* FIXME: Should we stop processes here, just to be safer? */
 	disable_nonboot_cpus();
-	device_suspend(3);
+	device_suspend(PM_SUSPEND_DISK);
 	do_magic(1);
 	panic("This never returns");
 

                 reply	other threads:[~2004-09-08 17:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200409081038.50387.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@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

all inboxes | Powered by JetHome®