History log of /drivers/acpi/processor_driver.c
Revision Date Author Comments
ea9c167d93e6e2f4697f5061756f26356793cd95 31-Jul-2014 Lan Tianyu <tianyu.lan@intel.com> ACPI / processor: Make acpi_cpu_soft_notify() process CPU FROZEN events

CPU hotplug happens during S2RAM and CPU notify event will be CPU_XXX_FROZEN.
acpi_cpu_soft_notify() ignores to check these events. This also may make
acpi_cpu_soft_notify() fall into sleep during CPU_DYING/STARTING_FROZEN
events which don't allow callbacks to sleep. This patch is to fix it.

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
8da8373447d6a57a5a9f55233d35beb15d92d0d2 08-May-2014 Toshi Kani <toshi.kani@hp.com> ACPI / processor: Fix STARTING/DYING action in acpi_cpu_soft_notify()

During CPU online/offline testing on a large system, one of the
processors got stuck after the message "bad: scheduling from the
idle thread!". The problem is that acpi_cpu_soft_notify() calls
acpi_bus_get_device() for all action types. CPU_STARTING and
CPU_DYING do not allow the notify handlers to sleep. However,
acpi_bus_get_device() can sleep in acpi_ut_acquire_mutex().

Change acpi_cpu_soft_notify() to return immediately for CPU_STARTING
and CPU_DYING as they have no action in this handler.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
07070e12cf5cab46a783a4753f07bb99e557473b 12-Mar-2014 Hanjun Guo <hanjun.guo@linaro.org> ACPI: Remove duplicate definitions of PREFIX

We already have a macro for PREFIX of "ACPI: " in
drivers/acpi/internal.h, so remove the duplicate ones
in ACPI drivers when internal.h is included.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
d0a7edbb6608d05b0718a0949be914067b5980fb 06-Dec-2013 Lan Tianyu <tianyu.lan@intel.com> ACPI / processor: use ACPI_COMPANION() to get ACPI device

Use ACPI_COMPANION() to get an ACPI device instead of
acpi_bus_get_device() in the processor driver.

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
34411a69a4925dd6de8e1069956f59d758da3ce9 30-Oct-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> 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>
764d022133979f9d9a179152cd89717e9752c61a 01-Oct-2013 Mathieu Rhéaume <mathieu@codingrhemes.com> ACPI / processor: fixed a brace coding style issue

Fixed a brace coding style issue. (Brace not on the good line)

Signed-off-by: Mathieu Rhéaume <mathieu@codingrhemes.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
22e7551eb6fd58352930306039a98313c011e615 13-Aug-2013 Lan Tianyu <tianyu.lan@intel.com> ACPI / processor: Remove acpi_processor_get_limit_info()

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 <tianyu.lan@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
1696d9dc57e062ce5200f6a42a6aaada15b434bb 15-Jul-2013 Thomas Renninger <trenn@suse.de> ACPI: Remove the old /proc/acpi/event interface

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 <trenn@suse.de>
Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
fe7bf106ebc22730797ba9b51308b166d68b77f9 19-Jun-2013 Paul Gortmaker <paul.gortmaker@windriver.com> acpi: delete __cpuinit usage from all acpi files

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 <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
86d6725a572d08e5e709871a77a7df137adf5ad4 24-Jun-2013 Hanjun Guo <hanjun.guo@linaro.org> ACPI / processor: Remove unused macros in processor_driver.c

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 <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2e4f1db49d97222110b6add9a2c6cf5251a41e35 30-May-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / processor: Initialize per_cpu(processors, pr->id) properly

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 <yinghai@kernel.org>
Reported-and-tested-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ac212b6980d8d5eda705864fc5a8ecddc6d6eacc 03-May-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / processor: Use common hotplug infrastructure

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 <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
0a3b15ac3cc3ddc791901e12bdc930b5fa11a30a 02-May-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / PM: Move processor suspend/resume to syscore_ops

The system suspend routine of the ACPI processor driver saves
the BUS_MASTER_RLD register and its resume routine restores it.
However, there can be only one such register in the system and it
really should be saved after non-boot CPUs have been offlined and
restored before they are put back online during resume.

For this reason, move the saving and restoration of BUS_MASTER_RLD
to syscore suspend and syscore resume, respectively, and drop the no
longer necessary suspend/resume callbacks from the ACPI processor
driver.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
9b27516fcd7ab7dc416edf418446c24c61729938 27-Feb-2013 Chen Gang <gang.chen@asianux.com> ACPI / porocessor: Beautify code, pr->id is u32 which is never < 0

pr->id is u32 which never < 0, so remove the redundant pr->id < 0
check from acpi_processor_add().

[rjw: Changelog]
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
76bba1423f6313ccf7bd7cd400f1f2049bbc740a 23-Feb-2013 Wen Congyang <wency@cn.fujitsu.com> cpu-hotplug, memory-hotplug: try offlining the node when hotremoving a cpu

The node will be offlined when all memory/cpu on the node is hotremoved.
So we should try offline the node when hotremoving a cpu on the node.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
3757b94802fb65d8f696597a74053cf21738da0b 13-Feb-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug: Fix concurrency issues and memory leaks

This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.

First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.

For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.

Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).

Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
51fac8388a0325a43f0ae67453ece2c373e2ec28 24-Jan-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI: Remove useless type argument of driver .remove() operation

The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field. For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
b8bd759acd05281abf88cddef30c57313c109697 19-Jan-2013 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead

The only difference between acpi_bus_scan() and acpi_bus_add() is the
invocation of acpi_update_all_gpes() in the latter which in fact is
unnecessary, because acpi_update_all_gpes() has already been called
by acpi_scan_init() and the way it is implemented guarantees the next
invocations of it to do nothing.

For this reason, drop acpi_bus_add() and make all its callers use
acpi_bus_scan() directly instead of it. Additionally, rearrange the
code in acpi_scan_init() slightly to improve the visibility of the
acpi_update_all_gpes() call in there.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
5993c4670ea2453ef5abb45b312f150e994e6eb9 11-Jan-2013 Yinghai Lu <yinghai@kernel.org> ACPI: update ej_event interface to take acpi_device

Should use acpi_device pointer directly instead of use handle and
get the device pointer again later.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
0cd6ac52b333f66ee64e50ed216ec99231092dcd 21-Dec-2012 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument

The callers of acpi_bus_add() usually assume that if it has
succeeded, then a struct acpi_device object has been attached to
the handle passed as the first argument. Unfortunately, however,
this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
too as a result, may return a pointer to a different struct
acpi_device object on success (it may be an object corresponding to
one of the descendant ACPI nodes in the namespace scope below that
handle).

For this reason, the callers of acpi_bus_add() who care about
whether or not a struct acpi_device object has been created for
its first argument need to check that using acpi_bus_get_device()
anyway, so the second argument of acpi_bus_add() is not really
useful for them. The same observation applies to acpi_bus_scan()
executed directly from acpi_scan_init().

Therefore modify the relevant callers of acpi_bus_add() to check the
existence of the struct acpi_device in question with the help of
acpi_bus_get_device() and drop the no longer necessary second
argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to
use acpi_bus_get_device() to get acpi_root and drop the no longer
needed second argument of acpi_bus_scan().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
636458de36f1fb4cdd318387d2f45604e451b17a 21-Dec-2012 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI: Remove the arguments of acpi_bus_add() that are not used

Notice that acpi_bus_add() uses only 2 of its 4 arguments and
redefine its header to match the body. Update all of its callers as
necessary and observe that this leads to quite a number of removed
lines of code (Linus will like that).

Add a kerneldoc comment documenting acpi_bus_add() and wonder how
its callers make wrong assumptions about the second argument (make
note to self to take care of that later).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
47db4547ffe5aa2eb5b053e6c02f0561fbbfa221 21-Nov-2012 Toshi Kani <toshi.kani@hp.com> ACPI: Update CPU hotplug error messages

Updated CPU hotplug error messages with acpi_handle_<level>(),
dev_<level>() and pr_<level>(). Modified some messages for
clarity. Added error status / id info to the messages where
needed.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
c5b18e22e74dc7dbd3f7729997a3a553ce761d2b 01-Nov-2012 Toshi Kani <toshi.kani@hp.com> ACPI: Add ACPI CPU hot-remove support

Added support of CPU hot-remove via an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
runs the hot-remove operation in kacpi_hotplug_wq and serializes
it between ACPI hot-remove and sysfs eject requests.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Tested-by: IgorMammedov <imammedo@redhat.com>
Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
5e5041f3527b36b58e864886ba34c179ad40ff92 23-Oct-2012 Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> ACPI / processor: prevent cpu from becoming online

Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().

Why does the patch change _cpu_up() logic?

The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it, there is the following race.

hot-remove cpu | _cpu_up()
------------------------------------- ------------------------------------
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus() |
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu() |
call acpi_unmap_lsapic() |
call put_online_cpus() |
| start and continue _cpu_up()
return acpi_processor_remove() |
continue hot-remove the cpu |

So _cpu_up() can continue to itself. And hot-remove cpu can also continue
itself. If the patch changes _cpu_up() logic, the race disappears as below:

hot-remove cpu | _cpu_up()
-----------------------------------------------------------------------
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus() |
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu() |
call acpi_unmap_lsapic() |
cpu's cpu_present is set |
to false by set_cpu_present()|
call put_online_cpus() |
| start _cpu_up()
| check cpu_present() and return -EINVAL
return acpi_processor_remove() |
continue hot-remove the cpu |

Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
879dca019dc43a1622edca3e7dde644b14b5acc5 26-Oct-2012 Alan Cox <alan@linux.intel.com> ACPI: missing break

We handle NOTIFY_THROTTLING so don't then fall through to unsupported event.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ed1511b80c92b1b1a8dde567adc090e470a4344a 15-Sep-2012 Daniel Lezcano <daniel.lezcano@linaro.org> ACPI / processor: remove pointless variable initialization

The 'errata' variable is a global variable which is set to zero,
no need to do that with a memset in the init function.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
38a991b625ae3898f18149f8fa287338647a4c9f 15-Sep-2012 Daniel Lezcano <daniel.lezcano@linaro.org> ACPI / processor: remove unused function parameter

The 'device' parameter is not used neither in acpi_processor_power_init
and acpi_processor_power_exit. This patch removes it.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
b7db60f45d74497c723dc7ae1370cf0b37dfb0d8 30-Jul-2012 Feng Tang <feng.tang@intel.com> ACPI processor: Fix tick_broadcast_mask online/offline regression

In commit 99b725084 "ACPI processor hotplug: Delay acpi_processor_start()
call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced
by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This
patch will restore it back, fixing the tick_broadcast_mask regression:
https://lkml.org/lkml/2012/7/30/169

Signed-off-by: Feng Tang <feng.tang@intel.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: <stable@vger.kernel.org> # 3.3+
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
25ac77613aa8fca131599705e3d7da2a0eaa06a0 05-Jul-2012 Daniel Lezcano <daniel.lezcano@linaro.org> ACPI: intel_idle : break dependency between modules

When the system is booted with some cpus offline, the idle
driver is not initialized. When a cpu is set online, the
acpi code call the intel idle init function. Unfortunately
this code introduce a dependency between intel_idle and acpi.

This patch is intended to remove this dependency by using the
notifier of intel_idle. This patch has the benefit of
encapsulating the intel_idle driver and remove some exported
functions.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
e8110b64af8b7cce96d1878276770c76cb9c01d5 27-Jun-2012 Rafael J. Wysocki <rjw@sisk.pl> ACPI: Use struct dev_pm_ops for power management in processor driver

Make the ACPI processor driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
51af3b9202ccffe0476899d5c29f0ae7e6bfdcea 24-May-2012 Toshi Kani <toshi.kani@hp.com> ACPI: Add _OST support for ACPI CPU hotplug

Changed acpi_processor_hotplug_notify() to call ACPI _OST method
when ACPI CPU hotplug operation has completed.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
c80f5b31f3c55a197f5323b93d1e3553429a427e 15-Mar-2012 Julia Lawall <Julia.Lawall@lip6.fr> ACPI: processor_driver: add missing kfree

The function acpi_processor_add is stored in the ops.add field of a
acpi_driver structure. This function is then called in
acpi_bus_driver_init. On failure, this function clears the field
device->driver_data, but does not free its contents. Thus the free has to
be done by the add function. In acpi_processor_add, the corresponding
value is pr. This value is currently freed on failure before storing it in
device->driver_data, but not after. This free is added in the error
handling code at the end of the function. The per_cpu variable
processors is also cleared so that it does not refer to a dangling pointer.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
9f324bda970c599ca35f7be89d9d1bcb96d6053c 19-Mar-2012 Toshi Kani <toshi.kani@hp.com> ACPI: Add CPU hotplug support for processor device objects

acpi_processor_install_hotplug_notify() registers processor objects to
receive ACPI CPU hotplug event notifications. This patch additionally
registers processor device objects (ACPI0007) to receive the notifications
as well.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Len Brown <len.brown@intel.com>
9ffc93f203c18a70623f21950f1dd473c9ec48cd 28-Mar-2012 David Howells <dhowells@redhat.com> Remove all #inclusions of asm/system.h

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`

Signed-off-by: David Howells <dhowells@redhat.com>
976a0be03a15f1c268e3f569c0ade3e7ff8ce478 07-Feb-2012 Yinghai Lu <yinghai@kernel.org> ACPI: remove duplicated lines of merging problems with acpi_processor_start

When checking driver-core tree, found crazying warnings on my setups.

[ 216.025849] calling acpi_processor_init+0x0/0x81 @ 1
[ 216.045332] ACPI: Requesting acpi_cpufreq
[ 216.047454] Monitor-Mwait will be used to enter C-1 state
[ 216.047912] Monitor-Mwait will be used to enter C-3 state
[ 216.065270] ACPI: acpi_idle registered with cpuidle
[ 216.068241] kobject (ffff8870364a1940): tried to init an initialized object, something is seriously wrong.
[ 216.085287] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc2-tip-yh-02428-ge663840-dirty #247
[ 216.105041] Call Trace:
[ 216.105192] [<ffffffff813a9c06>] kobject_init+0x33/0x83
[ 216.124880] [<ffffffff813aa1f8>] kobject_init_and_add+0x23/0x57
[ 216.125158] [<ffffffff819f3a08>] cpuidle_add_sysfs+0x49/0x62
[ 216.144850] [<ffffffff819f2a28>] __cpuidle_register_device+0xe6/0x10e
[ 216.145182] [<ffffffff819f2ea4>] cpuidle_register_device+0x25/0x4d
[ 216.164912] [<ffffffff81cb5774>] acpi_processor_power_init+0x13e/0x16c
[ 216.165205] [<ffffffff81427620>] ? acpi_processor_get_throttling_info+0x128/0x158
[ 216.185012] [<ffffffff81c68ae5>] acpi_processor_start+0x62/0x11d
[ 216.204861] [<ffffffff81cb55ff>] acpi_processor_add+0x1b0/0x1e7
[ 216.205144] [<ffffffff81402a7e>] acpi_device_probe+0x4e/0x11c
[ 216.225063] [<ffffffff8148f0e7>] really_probe+0x99/0x126
[ 216.225328] [<ffffffff8148f2a3>] driver_probe_device+0x3b/0x56
[ 216.244846] [<ffffffff8148f31d>] __driver_attach+0x5f/0x82
[ 216.245101] [<ffffffff8148f2be>] ? driver_probe_device+0x56/0x56
[ 216.264668] [<ffffffff8148db80>] bus_for_each_dev+0x5c/0x88
[ 216.264942] [<ffffffff8148eea7>] driver_attach+0x1e/0x20
[ 216.284639] [<ffffffff8148eaec>] bus_add_driver+0xca/0x21d
[ 216.284903] [<ffffffff81095827>] ? local_clock+0xf/0x3c
[ 216.304580] [<ffffffff82814177>] ? acpi_fan_init+0x18/0x18
[ 216.304849] [<ffffffff8148f79b>] driver_register+0x91/0xfe
[ 216.324545] [<ffffffff82814177>] ? acpi_fan_init+0x18/0x18
[ 216.324813] [<ffffffff81403705>] acpi_bus_register_driver+0x43/0x45
[ 216.344563] [<ffffffff828141a7>] acpi_processor_init+0x30/0x81
[ 216.344845] [<ffffffff82814177>] ? acpi_fan_init+0x18/0x18
[ 216.364590] [<ffffffff810001e7>] do_one_initcall+0x57/0x134
[ 216.364868] [<ffffffff827e6f8c>] kernel_init+0x146/0x1c0
[ 216.384512] [<ffffffff81d03aa4>] kernel_thread_helper+0x4/0x10
[ 216.384819] [<ffffffff81cfbb5d>] ? retint_restore_args+0xe/0xe
[ 216.404578] [<ffffffff827e6e46>] ? start_kernel+0x3ab/0x3ab
[ 216.424530] [<ffffffff81d03aa0>] ? gs_change+0xb/0xb
[ 216.424793] ------------[ cut here ]------------
[ 216.425038] WARNING: at fs/sysfs/dir.c:502 sysfs_add_one+0x97/0xab()
[ 216.444480] Hardware name: Sun Fire X4800
[ 216.444668] sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0/cpuidle'
...

It turns out acpi_processor_power_init() get called two time in acpi_processor_add and acpi_processor_start.

Found several lines are duplicated in those two functions even related commit move them.

The related patches are ok. Not sure how it could happen, looks like git problem.

-v2: add back acpi_processor_load_module(pr) to acpi_processor_load_start

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Thomas Renninger <trenn@suse.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
15f51136719699d7204eeeccd66849a4d90ae426 07-Feb-2012 Yinghai Lu <yinghai@kernel.org> ACPI: remove duplicated lines of merging problems with acpi_processor_add

Those lines have two copies.

Not sure how it could happen, looks like git problem.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
59c1204d464075fcb5d02e7daa6b23782dd4a088 07-Feb-2012 Yinghai Lu <yinghai@kernel.org> ACPI: remove duplicated lines of merging problems with acpi_processor_add

Those lines have two copies.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
9061e0e16700ef228837e96987ff51794c956197 26-Jan-2012 Andi Kleen <ak@linux.intel.com> ACPI: Load acpi-cpufreq from processor driver automatically

The only left over hole in automatic cpufreq driver loading was the loading
of ACPI cpufreq. This driver should be loaded when ACPI supports a _PDC
method and the CPU vendor wants to use acpi cpufreq.

Simply add a request module call to the acpi processor core driver
when this is true. This seems like the simplest solution for this.

Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
99b725084450bbc6f8e1ab20a0df4cc291c342b5 19-Jan-2012 Thomas Renninger <trenn@suse.de> ACPI processor hotplug: Delay acpi_processor_start() call for hotplugged cores

Delay the setting up of features (cpuidle, throttling by calling
acpi_processor_start()) to the time when the hotplugged
core got onlined the first time and got fully
initialized.

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
54d5dcc45af7adbb907072d042bbece4c2b4de6e 19-Jan-2012 Thomas Renninger <trenn@suse.de> ACPI processor hotplug: Split up acpi_processor_add

No functional change.

This is needed because:
When a CPU gets hotplugged, it's totally uninitialized
and offline. cpuinfo_x86 struct (cpu_data(cpu)) is mostly
zero (CPU feature flags, model, family,..).

When a CPU gets hotplugged, struct processor is alloc'd,
some sysfs files are set up but acpi_processor_add()
must not try to access a MSR on this CPU or try to read
out CPU feature,family, etc.

This must be done in acpi_processor_start().
The next patch will delay the call of acpi_processor_start()
for physically hotpluggedcores, to the time when they are onlined
the first time. There it is safe then to access cpu_data(cpu)
cpuinfo_x86 struct or access MSRs which is needed to
set up cpuidle, throttling and other features.

Tested and
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
3bd81a8710710f8bf5d1a5ebac315c842c20bdd3 17-Jan-2012 Thomas Renninger <trenn@suse.de> ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2

V2: Fix typo: pr->handle -> pr, here: acpi_processor_hotadd_init(pr)

This is a very small part taken from patches which afaik
are coming from Yunhong Jiang (for a Xen not a Linus repo?).

Cleanup only: no functional change.

Advantage (beside cleanup) is that other data of the pr (acpi_processor) struct
in the acpi_processor_hotadd_init() is needed later, for example a newly
introduced flag:
pr->flags.need_hotplug_init

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
5e7590d40dc59d5c1889d9e70c9da1f1df3918c6 17-Jan-2012 Thomas Renninger <trenn@suse.de> ACPI processor: Remove unneeded cpuidle_unregister_driver call

Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab registering
and unregistering cpuidle is done in processor_idle.c.
Unregistering via:
acpi_bus_unregister_driver(&acpi_processor_driver)
-> acpi_processor_remove()
-> acpi_processor_power_exit()

Remove not needed cpuidle_unregister_driver() call from
acpi_processor_exit

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
3333ea7804201918aa241641cf8493a62b8ad527 17-Nov-2011 Thomas Renninger <trenn@suse.de> ACPI processor: Fix error path, also remove sysdev link

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
8a25a2fd126c621f44f3aeaef80d51f00fc11639 21-Dec-2011 Kay Sievers <kay.sievers@vrfy.org> cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem

This moves the 'cpu sysdev_class' over to a regular 'cpu' subsystem
and converts the devices to regular devices. The sysdev drivers are
implemented as subsystem interfaces now.

After all sysdev classes are ported to regular driver core entities, the
sysdev implementation will be entirely removed from the kernel.

Userspace relies on events and generic sysfs subsystem infrastructure
from sysdev devices, which are made available with this conversion.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: Len Brown <lenb@kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
46bcfad7a819bd17ac4e831b04405152d59784ab 28-Oct-2011 Deepthi Dharwar <deepthi@linux.vnet.ibm.com> cpuidle: Single/Global registration of idle states

This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.

Having single/global registration of all the idle states,
dynamic C-state transitions on x86 are handled by
the boot cpu. Here, the boot cpu would disable all the devices,
re-populate the states and later enable all the devices,
irrespective of the cpu that would receive the notification first.

Reference:
https://lkml.org/lkml/2011/4/25/83

Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: Trinabh Gupta <g.trinabh@gmail.com>
Tested-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Len Brown <len.brown@intel.com>
6430c9c12a7dbb8f60f0d8294b73b3c0bb03f64f 17-Feb-2011 Jan Beulich <JBeulich@novell.com> ACPI: use __init where possible in processor driver

Use __init for several functions, remove an unnecessary export and a
stray use of __ref.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Len Brown <len.brown@intel.com>
5a344a505093dd65f82f338ffdb7208321b3630e 10-Jan-2011 Zhao Yakui <yakui.zhao@intel.com> ACPI: Reevaluate whether the T-state is supported or not after cpu is online/offline

After one CPU is offlined, it is unnecessary to switch T-state for it.
So it will be better that the throttling is disabled after the cpu
is offline.
At the same time after one cpu is online, we should check whether
the T-state is supported and then set the corresponding T-state
flag.

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
cef6e8a3790d6bdc305496629c357a56001d59a6 06-Dec-2010 Zhang Rui <rui.zhang@intel.com> ACPI processor: remove processor throttling control procfs I/F

Remove deprecated ACPI process procfs I/F for throttling control.

This is because the t-state control should only be done in kernel,
when system is in a overheating state.

Now users can only change the processor t-state indirectly,
by poking the cooling device sysfs I/F of the processor.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
5ba8b1c6fe40c314a02e28553c25552d8f1442e7 18-Oct-2010 Stephen Hemminger <shemminger@vyatta.com> ACPI: remove dead code

Found by running make namespacecheck on linux-next

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Len Brown <len.brown@intel.com>
d5c6887c7fbaf7a149c3bf441338fa833c529fb4 08-Oct-2010 Zhang Rui <rui.zhang@intel.com> ACPI processor: make /proc/acpi/processor/*/throttle depends on CONFIG_ACPI_PROCFS

As a feature that would only be used when system is overheating,
the processor t-state control should not be exported to user space.
Make /proc/acpi/processor/*/throttle depends on CONFIG_ACPI_PROCFS,
which is cleared by default.
And we will remove this I/F in 2.6.38.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
e9a64ed4994db04c9963495b03d8a86538e3ad55 25-Sep-2010 Len Brown <len.brown@intel.com> acpi_idle: add missing \n to printk

otherwise, these two lines print as one:

ACPI: acpi_idle yielding to intel_idle
ACPI: SSDT 3f5d8741 00203 (v02 PmRef Cpu0Ist 00003000 INTL 20050624)

Signed-off-by: Len Brown <len.brown@intel.com>
d09fe55510257f1acd21ea80a9bdd7c72b5895b3 15-Jul-2010 Zhang Rui <rui.zhang@intel.com> ACPI processor: remove deprecated ACPI procfs I/F

Remove deprecated ACPI processor procfs I/F, including:
/proc/acpi/processor/CPUX/power
/proc/acpi/processor/CPUX/limit
/proc/acpi/processor/CPUX/info

/proc/acpi/processor/CPUX/throttling still exists,
as we don't have sysfs I/F available for now.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
75cbfb97a156dd3dabdc81295fb8144576332366 26-May-2010 Thomas Renninger <trenn@suse.de> ACPI: Do not try to set up acpi processor stuff on cores exceeding maxcpus=

Patch is against latest Linus master branch and is expected to be
safe bug fix.

You get:
ACPI: HARDWARE addr space,NOT supported yet
for each ACPI defined CPU which status is active, but exceeds
maxcpus= count.

As these "not booted" CPUs do not run an idle routine
and echo X >/proc/acpi/processor/*/throttling did not work
I couldn't find a way to really access not onlined/booted
machines. Still this should get fixed and
/proc/acpi/processor/X dirs of cores exceeding maxcpus
should not show up.

I wonder whether this could get cleaned up by truncating possible cpu mask
and nr_cpu_ids to setup_max_cpus early some day
(and not exporting setup_max_cpus anymore then).
But this needs touching of a lot other places...

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: travis@sgi.com
CC: linux-acpi@vger.kernel.org
CC: lenb@kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>
2671717265ae6e720a9ba5f13fbec3a718983b65 08-Mar-2010 Len Brown <len.brown@intel.com> intel_idle: native hardware cpuidle driver for latest Intel processors

This EXPERIMENTAL driver supersedes acpi_idle on
Intel Atom Processors, Intel Core i3/i5/i7 Processors
and associated Intel Xeon processors.

It does not support the Intel Core2 processor or earlier.

For kernels configured with ACPI, CONFIG_INTEL_IDLE=y
allows intel_idle to probe before the ACPI processor driver.
Booting with "intel_idle.max_cstate=0" disables intel_idle
and the system will fall back on ACPI's "acpi_idle".

Typical Linux distributions load ACPI processor module early,
making CONFIG_INTEL_IDLE=m not easily useful on ACPI platforms.

intel_idle probes all processors at module_init time.
Processors that are hot-added later will be limited
to using C1 in idle.

Signed-off-by: Len Brown <len.brown@intel.com>
541adf7cd937b3895c7645406a9b060504df453b 22-May-2010 Len Brown <len.brown@intel.com> ACPI: allow a native cpuidle driver to displace ACPI

The ACPI driver would fail probe when it found that
another driver had previously registered with cpuidle.

But this is a natural situation, as a native hardware
cpuidle driver should be able to bind instead of ACPI,
and the ACPI processor driver should be able to handle
yielding control of C-states while still handling
P-states and T-states.

Add a KERN_DEBUG line showing when acpi_idle
does successfully register.

Signed-off-by: Len Brown <len.brown@intel.com>
5a0e3ad6af8660be21ca98a971cd00f331318c05 24-Mar-2010 Tejun Heo <tj@kernel.org> include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
d8191fa4a33fdc817277da4f2b7f771ff605a41c 22-Feb-2010 Alex Chiang <achiang@hp.com> ACPI: processor: driver doesn't need to evaluate _PDC

Now that the early _PDC evaluation path knows how to correctly
evaluate _PDC on only physically present processors, there's no
need for the processor driver to evaluate it later when it loads.

To cover the hotplug case, push _PDC evaluation down into the
hotplug paths.

Cc: x86@kernel.org
Cc: Tony Luck <tony.luck@intel.com>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
78ed8bd2944b6400f742306e5fe9d1b9b6bf18ba 22-Feb-2010 Alex Chiang <achiang@hp.com> ACPI: processor: move acpi_get_cpuid into processor_core.c

Enumerating processors (via MADT/_MAT) belongs in the processor core,
which is always built-in, rather than living in the processor driver
which may not be built.

Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2e9d5e4efa0beeca03ad550bda28027826e83e42 22-Feb-2010 Alex Chiang <achiang@hp.com> ACPI: processor: export acpi_get_cpuid()

Rename static get_cpu_id() to acpi_get_cpuid() and export it.

This change also gives us an opportunity to remove the
#ifndef CONFIG_SMP from processor_driver.c and into a header file
where it properly belongs.

Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
0131aa3dd7dcf41c66784b96ff351f63ee3ef348 22-Feb-2010 Alex Chiang <achiang@hp.com> ACPI: processor: mv processor_core.c processor_driver.c

The ACPI processor driver can be built as a module. But it has
pieces of code that should always be built statically into the
kernel.

The plan is for processor_core.c to contain the static bits while
processor_driver.c contains the module-like bits.

Since the bulk of the code in the current processor_core.c is
module-like, first step is to rename the file to processor_driver.c

Next step will re-create processor_core.c and cherry-pick out
the static bits.

Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>