From: Pavel Machek <pavel@suse.cz>
To: David Brownell <david-b@pacbell.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: [patch] enums to clear suspend-state confusion
Date: Wed, 18 Aug 2004 22:47:35 +0200 [thread overview]
Message-ID: <20040818204735.GE5395@elf.ucw.cz> (raw)
In-Reply-To: <200408180817.17822.david-b@pacbell.net>
Hi!
> The advantage of switching _now_ to enums is that it can be done
> without actually changing drivers ... however, there are actually
> two different suspend-state confusions. That patch just affects
> the first of them, whereas it's the second which actively breaks
> things today:
>
> - Confusion #1 ... "generic" PM framework uses a u32, and the
> meaning of that u32 has never been formally defined.
>
> In practice, most kernel code (except swsusp) passes an
> enum there already ... PM_SUSPEND_* values, which are
> unfortunately in an anonymous enum so there's no way
> even a smartened "sparse" could report errors.
>
> - Confusion #2 ... PCI suspend calls use a u32, which has since
> at least 2.4 meant a PCI power state. Those values are not
> the same as PM_SUSPEND_* values.
>
> PCI drivers that use that u32 are currently getting burnt by the
> way PM_SUSPEND_* values get passed in when the drivers
> expect a PCI power state. Example, passing PM_SUSPEND_MEM
> when the intention is PCI_D3hot (2 rather than 3).
>
> I happen to think the _right_ fix involves switching from a scalar to
> something that recognizes {bus,device,driver}-specific PM states.
That would not provide enough info for the driver.
> Such a switch would be extremely disruptive; it'd mean changing
> every driver. So it's something I'd not rush into ... it'd be worth
> doing as part of fixing multiple holes in the PM framework.
>
> Which leaves me thinking that the desirable near-term fix involves
> cleanup for #1, and minor sleight-of-hand to fix #2. Something
> like the attached patch (untested) ... which would let us answer
> Andrew's "why?" question by pointing to some bugtraq IDs.
I believe correct fix for #2 is what I've done. Pass enum system_state
down to driver, and make them use to_pci_state() helper. Fix of driver
then looks like:
--- clean/drivers/net/e100.c 2004-06-22 12:36:10.000000000 +0200
+++ linux/drivers/net/e100.c 2004-08-18 08:21:23.000000000 +0200
@@ -2269,7 +2269,7 @@
}
#ifdef CONFIG_PM
-static int e100_suspend(struct pci_dev *pdev, u32 state)
+static int e100_suspend(struct pci_dev *pdev, enum system_state state)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
@@ -2282,7 +2282,7 @@
pci_save_state(pdev, nic->pm_state);
pci_enable_wake(pdev, state, nic->flags & (wol_magic | e100_asf(nic)));
pci_disable_device(pdev);
- pci_set_power_state(pdev, state);
+ pci_set_power_state(pdev, to_pci_state(state));
return 0;
}
> +enum system_state {
> + PM_SUSPEND_ON = 0,
> + PM_SUSPEND_STANDBY = 1,
> + /* HACK ALERT: PM_SUSPEND_MEM == PCI_D3cold */
> + PM_SUSPEND_MEM = 3,
> + PM_SUSPEND_DISK = 4,
> PM_SUSPEND_MAX,
> };
Okay, I did not do this one. I'll probably just fix those drivers that
care, instead. The rest of patch was pretty much same as mine patch,
except:
> --- 1.86/kernel/power/swsusp.c Thu Jul 1 22:23:48 2004
> +++ edited/kernel/power/swsusp.c Wed Aug 18 07:48:04 2004
> @@ -699,7 +699,7 @@
> else
> #endif
> {
> - device_suspend(3);
> + device_suspend(PM_SUSPEND_DISK);
> device_shutdown();
> machine_power_off();
> }
this is no longer neccessary. -mm swsusp already uses right constants.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-08-18 20:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 12:02 [patch] enums to clear suspend-state confusion Pavel Machek
2004-08-16 0:59 ` Andrew Morton
2004-08-16 6:25 ` Pavel Machek
2004-08-16 14:09 ` Takashi Iwai
2004-08-16 20:11 ` Pavel Machek
2004-08-17 21:25 ` Pavel Machek
2004-08-17 22:27 ` Andrew Morton
2004-08-17 22:37 ` Pavel Machek
2004-08-17 23:12 ` Andrew Morton
2004-08-18 0:27 ` Pavel Machek
2004-08-18 2:04 ` Benjamin Herrenschmidt
2004-08-18 6:12 ` Pavel Machek
2004-08-18 6:55 ` Benjamin Herrenschmidt
2004-08-18 13:03 ` Pavel Machek
2004-08-18 14:29 ` Patrick Mochel
2004-08-18 15:17 ` David Brownell
2004-08-18 20:47 ` Pavel Machek [this message]
2004-08-18 17:31 ` Alan Cox
2004-08-18 18:28 ` David Brownell
2004-08-18 20:35 ` Pavel Machek
2004-08-18 6:26 ` Pavel Machek
2004-08-18 6:30 ` Andrew Morton
2004-08-18 10:22 ` Takashi Iwai
[not found] <566B962EB122634D86E6EE29E83DD808182C3774@hdsmsx403.hd.intel.com>
2004-08-19 5:59 ` Len Brown
2004-08-19 8:19 ` Pavel Machek
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=20040818204735.GE5395@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=david-b@pacbell.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 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.