From 764d022133979f9d9a179152cd89717e9752c61a Mon Sep 17 00:00:00 2001 From: Mathieu Rhéaume Date: Tue, 1 Oct 2013 05:29:39 -0400 Subject: ACPI / processor: fixed a brace coding style issue MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixed a brace coding style issue. (Brace not on the good line) Signed-off-by: Mathieu Rhéaume Signed-off-by: Rafael J. Wysocki --- drivers/acpi/processor_driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'drivers/acpi/processor_driver.c') diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index e534ba66d5b..40fc773ab6e 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -153,8 +153,7 @@ static int acpi_cpu_soft_notify(struct notifier_block *nfb, return NOTIFY_OK; } -static struct notifier_block __refdata acpi_cpu_notifier = -{ +static struct notifier_block __refdata acpi_cpu_notifier = { .notifier_call = acpi_cpu_soft_notify, }; -- cgit v1.2.3-70-g09d2 From 34411a69a4925dd6de8e1069956f59d758da3ce9 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 30 Oct 2013 00:00:30 +0100 Subject: 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 --- drivers/acpi/processor_driver.c | 1 - drivers/acpi/processor_perflib.c | 22 ---------------------- include/acpi/processor.h | 1 - 3 files changed, 24 deletions(-) (limited to 'drivers/acpi/processor_driver.c') diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index 40fc773ab6e..146ab7e2b81 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 51d7948611d..60a7c28fc16 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 7816e45f5d5..6eb1d3cb510 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); -- cgit v1.2.3-70-g09d2