linux/drivers/acpi/processor_driver.c, branch v3.13

ACPI / processor: Do not request ACPI cpufreq module directly

2013-10-29T23:00:30Z

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

ACPI / processor: fixed a brace coding style issue

2013-10-07T12:09:46Z

Fixed a brace coding style issue. (Brace not on the good line) Signed-off-by: Mathieu Rhéaume Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-processor'

2013-08-26T23:29:24Z

* acpi-processor: ACPI / processor: Acquire writer lock to update CPU maps ACPI / processor: Remove acpi_processor_get_limit_info()

Merge back earlier 'acpi-assorted' material

2013-08-14T21:22:45Z

ACPI / processor: Remove acpi_processor_get_limit_info()

2013-08-13T10:11:22Z

acpi_processor_get_limit_info() is only called in the __acpi_processor_start() and what it does actually is just to check pr->flags.throttling and set limit. The pr pointer has been checked in the __acpi_processor_start() before acpi_processor_get_limit_info() being called. It doesn't make sense still to keep it as a function. So move code to __acpi_processor_start() and remove acpi_processor_get_limit_info(). Signed-off-by: Lan Tianyu Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

ACPI: Remove the old /proc/acpi/event interface

2013-07-15T11:56:36Z

It is quite some time that this one has been deprecated. Get rid of it. Should some really important user be overseen, it may be reverted and the userspace program worked on first, but it is time to do something to get rid of this old stuff... Signed-off-by: Thomas Renninger Acked-by: Matthew Garrett Acked-by: Henrique de Moraes Holschuh Signed-off-by: Rafael J. Wysocki

acpi: delete __cpuinit usage from all acpi files

2013-07-14T23:36:58Z

The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/acpi uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Len Brown Cc: "Rafael J. Wysocki" Cc: linux-acpi@vger.kernel.org Signed-off-by: Paul Gortmaker

ACPI / processor: Remove unused macros in processor_driver.c

2013-06-24T10:58:43Z

ACPI_PROCESSOR_FILE_INFO, ACPI_PROCESSOR_FILE_THROTTLING and ACPI_PROCESSOR_FILE_LIMIT are used for procfs, but this feature was removed in commit d09fe555 (ACPI processor: remove deprecated ACPI procfs I/F) long ago. So, these macros should also be removed. ACPI_PROCESSOR_LIMIT_USER and ACPI_PROCESSOR_LIMIT_THERMAL are not used by any code, remove them too. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki

ACPI / processor: Initialize per_cpu(processors, pr->id) properly

2013-05-30T19:55:46Z

Commit ac212b6 (ACPI / processor: Use common hotplug infrastructure) forgot about initializing the per-CPU 'processors' variables which lead to ACPI cpuidle failure to use C-states and caused boot slowdown on multi-CPU machines. Fix the problem by adding per_cpu(processors, pr->id) initialization to acpi_processor_add() and add make acpi_processor_remove() clean it up as appropriate. Also modify acpi_processor_stop() so that it doesn't clear per_cpu(processors, pr->id) on processor driver removal which would then cause problems to happen when the driver is loaded again. This version of the patch contains fixes from Yinghai Lu. Reported-and-tested-by: Yinghai Lu Reported-and-tested-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki

ACPI / processor: Use common hotplug infrastructure

2013-05-12T12:14:32Z

Split the ACPI processor driver into two parts, one that is non-modular, resides in the ACPI core and handles the enumeration and hotplug of processors and one that implements the rest of the existing processor driver functionality. The non-modular part uses an ACPI scan handler object to enumerate processors on the basis of information provided by the ACPI namespace and to hook up with the common ACPI hotplug infrastructure. It also populates the ACPI handle of each processor device having a corresponding object in the ACPI namespace, which allows the driver proper to bind to those devices, and makes the driver bind to them if it is readily available (i.e. loaded) when the scan handler's .attach() routine is running. There are a few reasons to make this change. First, switching the ACPI processor driver to using the common ACPI hotplug infrastructure reduces code duplication and size considerably, even though a new file is created along with a header comment etc. Second, since the common hotplug code attempts to offline devices before starting the (non-reversible) removal procedure, it will abort (and possibly roll back) hot-remove operations involving processors if cpu_down() returns an error code for one of them instead of continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove is unset). That is a more desirable behavior than what the current code does. Finally, the separation of the scan/hotplug part from the driver proper makes it possible to simplify the driver's .remove() routine, because it doesn't need to worry about the possible cleanup related to processor removal any more (the scan/hotplug part is responsible for that now) and can handle device removal and driver removal symmetricaly (i.e. as appropriate). Some user-visible changes in sysfs are made (for example, the 'sysdev' link from the ACPI device node to the processor device's directory is gone and a 'physical_node' link is present instead and a corresponding 'firmware_node' is present in the processor device's directory, the processor driver is now visible under /sys/bus/cpu/drivers/ and bound to the processor device), but that shouldn't affect the functionality that users care about (frequency scaling, C-states and thermal management). Tested on my venerable Toshiba Portege R500. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Reviewed-by: Toshi Kani