|
@@ -1578,15 +1578,25 @@ void pci_pme_active(struct pci_dev *dev, bool enable)
|
|
|
|
|
|
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
|
|
|
|
|
|
- /* PCI (as opposed to PCIe) PME requires that the device have
|
|
|
- its PME# line hooked up correctly. Not all hardware vendors
|
|
|
- do this, so the PME never gets delivered and the device
|
|
|
- remains asleep. The easiest way around this is to
|
|
|
- periodically walk the list of suspended devices and check
|
|
|
- whether any have their PME flag set. The assumption is that
|
|
|
- we'll wake up often enough anyway that this won't be a huge
|
|
|
- hit, and the power savings from the devices will still be a
|
|
|
- win. */
|
|
|
+ /*
|
|
|
+ * PCI (as opposed to PCIe) PME requires that the device have
|
|
|
+ * its PME# line hooked up correctly. Not all hardware vendors
|
|
|
+ * do this, so the PME never gets delivered and the device
|
|
|
+ * remains asleep. The easiest way around this is to
|
|
|
+ * periodically walk the list of suspended devices and check
|
|
|
+ * whether any have their PME flag set. The assumption is that
|
|
|
+ * we'll wake up often enough anyway that this won't be a huge
|
|
|
+ * hit, and the power savings from the devices will still be a
|
|
|
+ * win.
|
|
|
+ *
|
|
|
+ * Although PCIe uses in-band PME message instead of PME# line
|
|
|
+ * to report PME, PME does not work for some PCIe devices in
|
|
|
+ * reality. For example, there are devices that set their PME
|
|
|
+ * status bits, but don't really bother to send a PME message;
|
|
|
+ * there are PCI Express Root Ports that don't bother to
|
|
|
+ * trigger interrupts when they receive PME messages from the
|
|
|
+ * devices below. So PME poll is used for PCIe devices too.
|
|
|
+ */
|
|
|
|
|
|
if (dev->pme_poll) {
|
|
|
struct pci_pme_device *pme_dev;
|