public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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