linux-toradex.git/drivers/acpi/processor_driver.c, branch v3.10.78

ACPI / PM: Move processor suspend/resume to syscore_ops

2013-05-12T12:03:14+00:00

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

ACPI / porocessor: Beautify code, pr->id is u32 which is never < 0

2013-03-04T13:23:39+00:00

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 
Signed-off-by: Rafael J. Wysocki

cpu-hotplug, memory-hotplug: try offlining the node when hotremoving a cpu

2013-02-24T01:50:13+00:00

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 
Signed-off-by: Tang Chen 
Cc: Yasuaki Ishimatsu 
Cc: David Rientjes 
Cc: Jiang Liu 
Cc: Minchan Kim 
Cc: KOSAKI Motohiro 
Cc: Mel Gorman 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Peter Zijlstra 
Cc: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ACPI / hotplug: Fix concurrency issues and memory leaks

2013-02-13T13:36:47+00:00

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 
Acked-by: Yinghai Lu

ACPI: Remove useless type argument of driver .remove() operation

2013-01-25T23:37:24+00:00

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 
Reviewed-by: Jiang Liu 
Acked-by: Toshi Kani 
Acked-by: Yinghai Lu

ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead

2013-01-19T00:27:35+00:00

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 
Acked-by: Yinghai Lu

ACPI: update ej_event interface to take acpi_device

2013-01-15T12:24:59+00:00

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

Signed-off-by: Yinghai Lu 
Signed-off-by: Rafael J. Wysocki

ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument

2013-01-03T12:09:40+00:00

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 
Acked-by: Yinghai Lu 
Acked-by: Toshi Kani

ACPI: Remove the arguments of acpi_bus_add() that are not used

2013-01-03T12:09:39+00:00

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 
Acked-by: Yinghai Lu 
Acked-by: Toshi Kani

ACPI: Update CPU hotplug error messages

2012-11-21T22:20:22+00:00

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

Signed-off-by: Toshi Kani 
Tested-by: Vijay Mohan Pandarathil 
Signed-off-by: Rafael J. Wysocki