aboutsummaryrefslogtreecommitdiff
path: root/drivers/idle
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2011-01-08 00:29:20 +0100
committerLen Brown <len.brown@intel.com>2011-01-12 12:47:30 -0500
commitd8c216cfa57e8a579f41729cbb88c97835d9ac8d (patch)
tree0085ebf22bf3a05607e512102a3dab065c5514a9 /drivers/idle
parentddbd550d503c9cdefcd6674a0ef168d57d3f0917 (diff)
cpuidle: Make cpuidle_enable_device() call poll_idle_init()
The following scenario is possible with the current cpuidle code and the ACPI cpuidle driver: (1) acpi_processor_cst_has_changed() is called, (2) cpuidle_disable_device() is called, (3) cpuidle_remove_state_sysfs() is called to remove the (presumably outdated) states info from sysfs, (3) acpi_processor_get_power_info() is called, the first entry in the pr->power.states[] table is filled with zeros, (4) acpi_processor_setup_cpuidle() is called and it doesn't fill the first entry in pr->power.states[], (5) cpuidle_enable_device() is called, (6) __cpuidle_register_device() is _not_ called, since the device has already been registered, (7) Consequently, poll_idle_init() is _not_ called either, (8) cpuidle_add_state_sysfs() is called to create the sysfs attributes for the new states and it uses the bogus first table entry from acpi_processor_get_power_info() for creating state0. This problem is avoided if cpuidle_enable_device() unconditionally calls poll_idle_init(). Reported-by: Len Brown <len.brown@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com> cc: stable@kernel.org
Diffstat (limited to 'drivers/idle')
0 files changed, 0 insertions, 0 deletions