From: Pavel Machek <pavel@suse.cz>
To: benh@kernel.crashing.org,
kernel list <linux-kernel@vger.kernel.org>,
Patrick Mochel <mochel@digitalimplant.org>,
david-b@pacbell.net, dbrownell@users.sourceforge.net
Subject: Solving suspend-level confusion
Date: Fri, 30 Jul 2004 18:44:13 +0200 [thread overview]
Message-ID: <20040730164413.GB4672@elf.ucw.cz> (raw)
Hi!
There's quite big confusion what 'u32 state' in suspend callbacks
mean. Half code interprets it as a system-wide suspend level, and
second half thinks it is PCI Dx state. Bad.
What about this solution:
* system-wide suspend level is always passed down (it is more
detailed, and for example IDE driver cares)
* if you want to derive Dx state, just use provided inline function to
convert.
That should be acceptable to everyone. I plan on explicitly using
enums to prevent further confusion. Patch is likely to be pretty big:
ideally all prototypes of suspend function would be fixed so noone can
be confused.
What do you think?
Pavel
PS: I'll be on holidays for a week, feel free to implement this or
something similar.. it is going to be lot of search/replace in drivers
:-(.
--- tmp/linux/include/linux/pci.h 2004-06-22 12:36:45.000000000 +0200
+++ linux/include/linux/pci.h 2004-07-30 18:24:02.000000000 +0200
@@ -593,7 +593,7 @@
const struct pci_device_id *id_table; /* must be non-NULL for probe to be called */
int (*probe) (struct pci_dev *dev, const struct pci_device_id *id); /* New device inserted */
void (*remove) (struct pci_dev *dev); /* Device removed (NULL if not a hot-plug capable driver) */
- int (*suspend) (struct pci_dev *dev, u32 state); /* Device suspended */
+ int (*suspend) (struct pci_dev *dev, enum suspend_state reason); /* Device suspended */
int (*resume) (struct pci_dev *dev); /* Device woken up */
int (*enable_wake) (struct pci_dev *dev, u32 state, int enable); /* Enable wake event */
--- tmp/linux/include/linux/pm.h 2004-06-22 12:36:45.000000000 +0200
+++ linux/include/linux/pm.h 2004-07-30 18:23:11.000000000 +0200
@@ -193,11 +193,11 @@
extern void (*pm_idle)(void);
extern void (*pm_power_off)(void);
-enum {
- PM_SUSPEND_ON,
- PM_SUSPEND_STANDBY,
- PM_SUSPEND_MEM,
- PM_SUSPEND_DISK,
+enum system_state {
+ PM_SUSPEND_ON = 0,
+ PM_SUSPEND_STANDBY = 1,
+ PM_SUSPEND_MEM = 2,
+ PM_SUSPEND_DISK = 3,
PM_SUSPEND_MAX,
};
@@ -241,11 +240,47 @@
extern void device_pm_set_parent(struct device * dev, struct device * parent);
-extern int device_suspend(u32 state);
-extern int device_power_down(u32 state);
+enum suspend_state {
+ SNAPSHOT = 10, /* For debugging, symbolic constants should be everywhere */
+ POWERDOWN,
+ RESTART,
+ RUNTIME_D1,
+ RUNTIME_D2,
+ RUNTIME_D3hot,
+ RUNTIME_D3cold
+};
+
+extern int device_suspend(enum suspend_state reason);
+extern int device_power_down(enum suspend_state reason);
extern void device_power_up(void);
extern void device_resume(void);
+enum pci_state {
+ D0 = 20, /* For debugging, symbolic constants should be everywhere */
+ D1,
+ D2,
+ D3hot,
+ D3cold
+};
+
+static inline enum pci_state to_pci_state(enum suspend_state state)
+{
+ switch(state) {
+ case RUNTIME_D1:
+ return D1;
+ case RUNTIME_D2:
+ return D2;
+ case RUNTIME_D3hot:
+ return D3hot;
+ case SNAPSHOT:
+ case POWERDOWN:
+ case RESTART:
+ case RUNTIME_D3cold:
+ return D3cold;
+ default:
+ BUG();
+ }
+}
#endif /* __KERNEL__ */
--- tmp/linux/kernel/power/disk.c 2004-05-20 23:08:36.000000000 +0200
+++ linux/kernel/power/disk.c 2004-07-30 18:18:04.000000000 +0200
@@ -46,20 +46,25 @@
int error = 0;
local_irq_save(flags);
- device_power_down(PM_SUSPEND_DISK);
switch(mode) {
case PM_DISK_PLATFORM:
+ device_power_down(POWERDOWN);
error = pm_ops->enter(PM_SUSPEND_DISK);
break;
case PM_DISK_SHUTDOWN:
+ device_power_down(POWERDOWN);
printk("Powering off system\n");
machine_power_off();
break;
case PM_DISK_REBOOT:
+ device_power_down(RESTART);
machine_restart(NULL);
break;
}
machine_halt();
+ /* Valid image is on the disk, if we continue we risk serious data corruption
+ after resume. */
+ while(1);
device_power_up();
local_irq_restore(flags);
return 0;
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next reply other threads:[~2004-07-30 16:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-30 16:44 Pavel Machek [this message]
2004-07-30 22:39 ` Benjamin Herrenschmidt
2004-07-30 23:06 ` Pavel Machek
2004-07-31 4:02 ` David Brownell
2004-07-31 4:36 ` Pavel Machek
2004-07-31 5:49 ` Benjamin Herrenschmidt
2004-07-31 14:23 ` David Brownell
2004-07-31 17:01 ` Oliver Neukum
2004-07-31 17:51 ` David Brownell
2004-08-01 0:41 ` David Brownell
2004-08-01 1:34 ` Benjamin Herrenschmidt
2004-08-02 16:38 ` David Brownell
2004-08-03 0:38 ` Benjamin Herrenschmidt
2004-08-04 2:28 ` David Brownell
2004-08-04 2:26 ` Nigel Cunningham
2004-08-04 2:53 ` Benjamin Herrenschmidt
2004-08-04 2:52 ` Nigel Cunningham
2004-08-04 4:14 ` Benjamin Herrenschmidt
2004-08-04 4:25 ` Nigel Cunningham
2004-08-04 4:52 ` Benjamin Herrenschmidt
2004-08-04 4:54 ` Nigel Cunningham
2004-08-04 5:03 ` Benjamin Herrenschmidt
2004-08-04 5:05 ` Nigel Cunningham
2004-08-05 10:05 ` Nigel Cunningham
2004-08-05 22:31 ` Nigel Cunningham
2004-08-06 0:39 ` Benjamin Herrenschmidt
2004-08-06 21:30 ` Pavel Machek
2004-08-06 21:29 ` Pavel Machek
2004-08-06 22:27 ` Benjamin Herrenschmidt
2004-08-06 22:37 ` Pavel Machek
2004-08-06 21:26 ` Pavel Machek
2004-08-05 1:29 ` David Brownell
2004-08-05 10:19 ` Nigel Cunningham
2004-08-06 0:32 ` David Brownell
[not found] ` <1091772799.2532.50.camel@laptop.cunninghams>
2004-08-07 22:24 ` David Brownell
2004-08-04 2:56 ` Benjamin Herrenschmidt
2004-08-04 3:30 ` David Brownell
2004-08-04 4:19 ` Benjamin Herrenschmidt
2004-08-04 4:47 ` What PM should be and do (Was Re: Solving suspend-level confusion) Nigel Cunningham
2004-08-04 4:53 ` Benjamin Herrenschmidt
2004-08-04 4:59 ` Nigel Cunningham
2004-08-08 16:54 ` Pavel Machek
2004-08-08 21:55 ` Nigel Cunningham
2004-08-09 8:42 ` Pavel Machek
2004-08-05 18:19 ` Greg KH
2004-08-05 22:14 ` Nigel Cunningham
2004-08-07 0:08 ` Éric Brunet
2004-08-08 19:48 ` Pavel Machek
2004-08-11 21:23 ` Greg KH
2004-08-08 0:54 ` David Brownell
2004-08-06 21:21 ` Solving suspend-level confusion Pavel Machek
2004-07-31 21:09 ` Benjamin Herrenschmidt
2004-08-02 16:40 ` David Brownell
2004-08-03 0:50 ` Benjamin Herrenschmidt
2004-08-07 23:30 ` David Brownell
2004-08-06 21:10 ` Pavel Machek
2004-08-07 23:23 ` David Brownell
2004-08-08 17:16 ` Pavel Machek
2004-08-06 20:04 ` Pavel Machek
2004-08-07 22:14 ` David Brownell
2004-08-07 23:53 ` Benjamin Herrenschmidt
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=20040730164413.GB4672@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=benh@kernel.crashing.org \
--cc=david-b@pacbell.net \
--cc=dbrownell@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.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®