diff options
| author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-10-30 00:00:30 +0100 |
|---|---|---|
| committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-10-30 00:00:30 +0100 |
| commit | 34411a69a4925dd6de8e1069956f59d758da3ce9 (patch) | |
| tree | b861bf6803e8468fb3cb3f663ac76d6d868877d5 | |
| parent | 764d022133979f9d9a179152cd89717e9752c61a (diff) | |
| download | talos-op-linux-34411a69a4925dd6de8e1069956f59d758da3ce9.tar.gz talos-op-linux-34411a69a4925dd6de8e1069956f59d758da3ce9.zip | |
ACPI / processor: Do not request ACPI cpufreq module directly
Function acpi_processor_load_module() used by the ACPI processor
driver can only really work if the acpi-cpufreq module is available
when acpi_processor_start() is executed which usually is not the case
for systems loading the processor driver module from an initramfs.
Moreover, that used to be a hackish workaround for module autoloading
issues, but udev loads acpi-cpufreq just fine nowadays, so that
function isn't really necessary any more. For this reason, drop
acpi_processor_load_module() entirely.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| -rw-r--r-- | drivers/acpi/processor_driver.c | 1 | ||||
| -rw-r--r-- | drivers/acpi/processor_perflib.c | 22 | ||||
| -rw-r--r-- | include/acpi/processor.h | 1 |
3 files changed, 0 insertions, 24 deletions
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index 40fc773ab6e0..146ab7e2b81d 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -171,7 +171,6 @@ static int __acpi_processor_start(struct acpi_device *device) #ifdef CONFIG_CPU_FREQ acpi_processor_ppc_has_changed(pr, 0); - acpi_processor_load_module(pr); #endif acpi_processor_get_throttling_info(pr); diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index 51d7948611da..60a7c28fc167 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -235,28 +235,6 @@ void acpi_processor_ppc_exit(void) acpi_processor_ppc_status &= ~PPC_REGISTERED; } -/* - * Do a quick check if the systems looks like it should use ACPI - * cpufreq. We look at a _PCT method being available, but don't - * do a whole lot of sanity checks. - */ -void acpi_processor_load_module(struct acpi_processor *pr) -{ - static int requested; - acpi_status status = 0; - struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; - - if (!arch_has_acpi_pdc() || requested) - return; - status = acpi_evaluate_object(pr->handle, "_PCT", NULL, &buffer); - if (!ACPI_FAILURE(status)) { - printk(KERN_INFO PREFIX "Requesting acpi_cpufreq\n"); - request_module_nowait("acpi_cpufreq"); - requested = 1; - } - kfree(buffer.pointer); -} - static int acpi_processor_get_performance_control(struct acpi_processor *pr) { int result = 0; diff --git a/include/acpi/processor.h b/include/acpi/processor.h index 7816e45f5d5a..6eb1d3cb5104 100644 --- a/include/acpi/processor.h +++ b/include/acpi/processor.h @@ -225,7 +225,6 @@ struct acpi_processor_errata { } piix4; }; -extern void acpi_processor_load_module(struct acpi_processor *pr); extern int acpi_processor_preregister_performance(struct acpi_processor_performance __percpu *performance); |
