diff options
author | Rafael J. Wysocki <rjw@sisk.pl> | 2011-01-08 00:29:20 +0100 |
---|---|---|
committer | Len Brown <len.brown@intel.com> | 2011-01-12 12:47:30 -0500 |
commit | d8c216cfa57e8a579f41729cbb88c97835d9ac8d (patch) | |
tree | 0085ebf22bf3a05607e512102a3dab065c5514a9 /drivers/acpi | |
parent | ddbd550d503c9cdefcd6674a0ef168d57d3f0917 (diff) | |
download | linux-d8c216cfa57e8a579f41729cbb88c97835d9ac8d.tar.bz2 |
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/acpi')
0 files changed, 0 insertions, 0 deletions