lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 29 Jan 2013 12:34:15 +0800
From:	Huang Ying <ying.huang@...el.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-pm@...r.kernel.org, linux-acpi@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Huang Ying <ying.huang@...el.com>
Subject: [PATCH 1/4] PCI/ACPI: Add target state as parameter to pci_platform_pm_ops->run_wake

Normally, if PCI device uses native PME interrupt for runtime wake up,
platform need not to do anything for runtime wake up.

But per PCI Express Base Specification Revision 2.0 section 5.3.3.2
Link Wakeup, platform support is needed for D3cold waking up to power
on the main link even if there is native PME interrupt support for
D3cold.

So the needed work for platform runtime wake up is different among
different target state.  Originally, pci_dev->runtime_d3cold flag is
used for that, but we want to restrict its usage.  Now the target
state is added as parameter to pci_platform_pm_ops->run_wake to solve
the issue.

Signed-off-by: Huang Ying <ying.huang@...el.com>
---
 drivers/pci/pci-acpi.c |    5 +++--
 drivers/pci/pci.c      |    9 +++++----
 drivers/pci/pci.h      |    2 +-
 3 files changed, 9 insertions(+), 7 deletions(-)

--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -261,7 +261,8 @@ static void acpi_pci_propagate_run_wake(
 		acpi_pm_device_run_wake(bus->bridge, enable);
 }
 
-static int acpi_pci_run_wake(struct pci_dev *dev, bool enable)
+static int acpi_pci_run_wake(struct pci_dev *dev, bool enable,
+			     pci_power_t state)
 {
 	/*
 	 * Per PCI Express Base Specification Revision 2.0 section
@@ -269,7 +270,7 @@ static int acpi_pci_run_wake(struct pci_
 	 * waking up to power on the main link even if there is PME
 	 * support for D3cold
 	 */
-	if (dev->pme_interrupt && !dev->runtime_d3cold)
+	if (dev->pme_interrupt && state != PCI_D3cold)
 		return 0;
 
 	if (!acpi_pm_device_run_wake(&dev->dev, enable))
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -484,10 +484,11 @@ static inline int platform_pci_sleep_wak
 			pci_platform_pm->sleep_wake(dev, enable) : -ENODEV;
 }
 
-static inline int platform_pci_run_wake(struct pci_dev *dev, bool enable)
+static inline int platform_pci_run_wake(struct pci_dev *dev, bool enable,
+					pci_power_t state)
 {
 	return pci_platform_pm ?
-			pci_platform_pm->run_wake(dev, enable) : -ENODEV;
+			pci_platform_pm->run_wake(dev, enable, state) : -ENODEV;
 }
 
 /**
@@ -1687,7 +1688,7 @@ int __pci_enable_wake(struct pci_dev *de
 			pci_pme_active(dev, true);
 		else
 			ret = 1;
-		error = runtime ? platform_pci_run_wake(dev, true) :
+		error = runtime ? platform_pci_run_wake(dev, true, state) :
 					platform_pci_sleep_wake(dev, true);
 		if (ret)
 			ret = error;
@@ -1695,7 +1696,7 @@ int __pci_enable_wake(struct pci_dev *de
 			dev->wakeup_prepared = true;
 	} else {
 		if (runtime)
-			platform_pci_run_wake(dev, false);
+			platform_pci_run_wake(dev, false, state);
 		else
 			platform_pci_sleep_wake(dev, false);
 		pci_pme_active(dev, false);
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -61,7 +61,7 @@ struct pci_platform_pm_ops {
 	pci_power_t (*choose_state)(struct pci_dev *dev);
 	bool (*can_wakeup)(struct pci_dev *dev);
 	int (*sleep_wake)(struct pci_dev *dev, bool enable);
-	int (*run_wake)(struct pci_dev *dev, bool enable);
+	int (*run_wake)(struct pci_dev *dev, bool enable, pci_power_t state);
 };
 
 extern int pci_set_platform_pm(struct pci_platform_pm_ops *ops);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ