Merge branches 'pm-cpufreq', 'pm-pci' and 'pm-sleep'

Merge fixes for the ondemand and conservative cpufreq governors,
PCI power management and system wakeup framework.

* pm-cpufreq:
  cpufreq: governor: Avoid accessing invalid governor_data

* pm-pci:
  PCI / ACPI / PM: Resume all bridges on suspend-to-RAM

* pm-sleep:
  PM / sleep: wakeup: Fix build error caused by missing SRCU support

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 1d50e97d49f192cd8bf1c5eb0ce569e9641cf43e..6d53f7d9fc7a92d415b507f9b8facdb3f4143b17 100644 (file)
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -555,12 +555,20 @@ EXPORT_SYMBOL_GPL(cpufreq_dbs_governor_stop);
 
 void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy)
 {
-       struct policy_dbs_info *policy_dbs = policy->governor_data;
+       struct policy_dbs_info *policy_dbs;
+
+       /* Protect gov->gdbs_data against cpufreq_dbs_governor_exit() */
+       mutex_lock(&gov_dbs_data_mutex);
+       policy_dbs = policy->governor_data;
+       if (!policy_dbs)
+               goto out;
 
        mutex_lock(&policy_dbs->update_mutex);
        cpufreq_policy_apply_limits(policy);
        gov_update_sample_delay(policy_dbs, 0);
-
        mutex_unlock(&policy_dbs->update_mutex);
+
+out:
+       mutex_unlock(&gov_dbs_data_mutex);
 }
 EXPORT_SYMBOL_GPL(cpufreq_dbs_governor_limits);

diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 89ee6a2b6eb838f426d6d9d3773f70769d1a489f..5d1698265da5211e998729bb3499f9e81131dfb3 100644 (file)
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -632,13 +632,11 @@ static bool acpi_pci_need_resume(struct pci_dev *dev)
        /*
         * In some cases (eg. Samsung 305V4A) leaving a bridge in suspend over
         * system-wide suspend/resume confuses the platform firmware, so avoid
-        * doing that, unless the bridge has a driver that should take care of
-        * the PM handling.  According to Section 16.1.6 of ACPI 6.2, endpoint
+        * doing that.  According to Section 16.1.6 of ACPI 6.2, endpoint
         * devices are expected to be in D3 before invoking the S3 entry path
         * from the firmware, so they should not be affected by this issue.
         */
-       if (pci_is_bridge(dev) && !dev->driver &&
-           acpi_target_system_state() != ACPI_STATE_S0)
+       if (pci_is_bridge(dev) && acpi_target_system_state() != ACPI_STATE_S0)
                return true;
 
        if (!adev || !acpi_device_power_manageable(adev))

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index e880ca22c5a589127b5c7f7023434e99e090972b..3a6c2f87699e355e1772aa1320aa556e7201743b 100644 (file)
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -105,6 +105,7 @@ config PM_SLEEP
        def_bool y
        depends on SUSPEND || HIBERNATE_CALLBACKS
        select PM
+       select SRCU
 
 config PM_SLEEP_SMP
        def_bool y