From: David Brownell <david-b@pacbell.net>
To: linux-kernel@vger.kernel.org
Subject: PATCH/RFC: pci wakeup hooks (2/4)
Date: Mon, 4 Oct 2004 14:03:00 -0700 [thread overview]
Message-ID: <200410041403.00219.david-b@pacbell.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 69 bytes --]
This adds minimal PCI hooks. Maybe they should be more minimal.
[-- Attachment #2: wake-pci.patch --]
[-- Type: text/x-diff, Size: 1963 bytes --]
This makes PCI use the new pmcore wakeup bits.
- Initialized in pci_enable_device()
- Disabled in pci_disable_device()
- Lets userspace change the initial may_wakeup policy.
Previously, wakeup policies were driver-specific (other than ethtool).
This patch lets all drivers outsource such decisions.
NOTE: the init could presumably be done in probe() and never changed,
except maybe when ACPI and PCI disagree. But since I (mis?)remember
hearing about devices that choke on capability accesses during probe(),
it's done this way instead.
ALSO: I think some boards can support system wakeup using signals other
then PME# ... handling wakeup without PCI PM. Presumably board-specific
logic (ACPI bytecodes?) would kick in to mark the devices appropriately;
playing well with such logic might mean never clearing can_wakeup.
[ against 2.6.9-rc3 ]
--- 1.70/drivers/pci/pci.c Wed Aug 4 18:20:19 2004
+++ edited/drivers/pci/pci.c Mon Oct 4 12:42:04 2004
@@ -382,6 +382,16 @@
int
pci_enable_device(struct pci_dev *dev)
{
+#ifdef CONFIG_PM
+ /* with PCI PM capability, it can maybe issue PME# */
+ u16 pm = pci_find_capability(dev, PCI_CAP_ID_PM);
+ device_init_wakeup(&dev->dev, 0);
+ if (pm) {
+ pci_read_config_word(dev, pm + PCI_PM_PMC, &pm);
+ if (pm & PCI_PM_CAP_PME)
+ device_init_wakeup(&dev->dev, 1);
+ }
+#endif
dev->is_enabled = 1;
return pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1);
}
@@ -400,6 +410,7 @@
dev->is_enabled = 0;
dev->is_busmaster = 0;
+ device_init_wakeup(&dev->dev, 0);
pci_read_config_word(dev, PCI_COMMAND, &pci_command);
if (pci_command & PCI_COMMAND_MASTER) {
@@ -434,6 +445,10 @@
* wake events, it's a nop; otherwise fail */
if (!pm)
return enable ? -EIO : 0;
+
+ /* don't enable unless driver core lets us */
+ if (!device_may_wakeup(&dev->dev) && enable)
+ return -EROFS;
/* Check device's ability to generate PME# */
pci_read_config_word(dev,pm+PCI_PM_PMC,&value);
reply other threads:[~2004-10-04 21:35 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=200410041403.00219.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.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