linux-stable.git/drivers/acpi, branch v3.12.2

ACPI / hotplug: Do not execute "insert in progress" _OST

2013-11-29T19:27:56+00:00

commit 176a88d79d6b5aebabaff16734e8b3107efcaaad upstream.

According to the ACPI spec (5.0, Section 6.3.5), the "Device
insertion in progress (pending)" (0x80) _OST status code is
reserved for the "Insertion Processing" (0x200) source event
which is "a result of an OSPM action".  Specifically, it is not
a notification, so that status code should not be used during
notification processing, which unfortunately is done by
acpi_scan_bus_device_check().

For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST
status evaluation from there (it was a mistake to put it in there
in the first place).

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / hotplug: Fix handle_root_bridge_removal()

2013-11-29T19:27:55+00:00

commit 2441191a19039002b2c454a261fb45986df15184 upstream.

It is required to do get_device() on the struct acpi_device in
question before passing it to acpi_bus_hot_remove_device() through
acpi_os_hotplug_execute(), because acpi_bus_hot_remove_device()
calls acpi_scan_hot_remove() that does put_device() on that
object.

The ACPI PCI root removal routine, handle_root_bridge_removal(),
doesn't do that, which may lead to premature freeing of the
device object or to executing put_device() on an object that
has been freed already.

Fix this problem by making handle_root_bridge_removal() use
get_device() as appropriate.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Toshi Kani 
Signed-off-by: Greg Kroah-Hartman

ACPI / video: Quirk initial backlight level 0

2013-11-29T19:27:55+00:00

commit 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 upstream.

Some firmware doesn't initialize initial backlight level to a proper
value and _BQC will return 0 on first time evaluation. We used to be
able to detect such incorrect value with our code logic, as value 0
normally isn't a valid value in _BCL. But with the introduction of Win8,
firmware begins to fill _BCL with values from 0 to 100, now 0 becomes
a valid value but that value will make user's screen black. This patch
test initial _BQC for value 0, if such a value is returned, do not use
it.

References: https://bugzilla.kernel.org/show_bug.cgi?id=64031
References: https://bugzilla.kernel.org/show_bug.cgi?id=61231
References: https://bugzilla.kernel.org/show_bug.cgi?id=63111
Reported-by: Qingshuai Tian 
Tested-by: Aaron Lu  # on "Idealpad u330p"
Reported-and-tested-by:  # on "Acer Aspire V5-573G"
Reported-and-tested-by: Kirill Tkhai  # on "HP 250 G1"
Signed-off-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Ensure lock is acquired before accessing ec struct members

2013-11-29T19:27:55+00:00

commit 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb upstream.

A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug
info and trivial code cleanup') that erroneously caused the struct member
to be accessed before acquiring the required lock.  This change fixes
it by ensuring the lock acquisition is done first.

Found by Aaron Durbin 

Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup')
References: http://crbug.com/319019
Signed-off-by: Puneet Kumar 
Reviewed-by: Aaron Durbin 
[olof: Commit message reworded a bit]
Signed-off-by: Olof Johansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

sched, idle: Fix the idle polling state logic

2013-11-29T19:27:55+00:00

commit ea8117478918a4734586d35ff530721b682425be upstream.

Mike reported that commit 7d1a9417 ("x86: Use generic idle loop")
regressed several workloads and caused excessive reschedule
interrupts.

The patch in question failed to notice that the x86 code had an
inverted sense of the polling state versus the new generic code (x86:
default polling, generic: default !polling).

Fix the two prominent x86 mwait based idle drivers and introduce a few
new generic polling helpers (fixing the wrong smp_mb__after_clear_bit
usage).

Also switch the idle routines to using tif_need_resched() which is an
immediate TIF_NEED_RESCHED test as opposed to need_resched which will
end up being slightly different.

Reported-by: Mike Galbraith 
Signed-off-by: Peter Zijlstra 
Cc: lenb@kernel.org
Cc: tglx@linutronix.de
Link: http://lkml.kernel.org/n/tip-nc03imb0etuefmzybzj7sprf@git.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Drop two functions that are not used any more

2013-10-17T13:44:48+00:00

Two functions defined in device_pm.c, acpi_dev_pm_add_dependent()
and acpi_dev_pm_remove_dependent(), have no callers and may be
dropped, so drop them.

Moreover, they are the only functions adding entries to and removing
entries from the power_dependent list in struct acpi_device, so drop
that list too.

Signed-off-by: Rafael J. Wysocki

ACPI / power: Drop automaitc resume of power resource dependent devices

2013-10-16T21:05:42+00:00

The mechanism causing devices depending on a given power resource
(that is, devices that can be in D0 only if that power resource is
on) to be resumed automatically when the power resource is turned
on (and their "inferred" power state becomes D0 as a result) is
inherently racy and in fact unnecessary.

It is racy, because if the power resource is turned on and then
immediately off, the device resume triggered by the first transition
to "on" may still happen, causing the power resource to be turned
on again.  That again will trigger the "resume of dependent devices"
mechanism, but if the devices in question are not in use, they will
be suspended in the meantime causing the power resource to be turned
off.  However, the "resume of dependent devices" will next resume
them again and so on.  In some cases (USB port PM in particular) that
leads to an endless busy loop of flipping the resource on and off
continuously.

It is needless, because whoever turns a power resource on will most
likely turn it off at some point and the devices that go into "D0"
as a result of turning it on will then go back into D3cold
(generally, the state they were in before).

Moreover, turning on all power resources a device needs to go into
D0 is not sufficient for a full transition into D0 in general.
Namely, _PS0 may need to be executed in addition to that in some
cases.  This means that the whole rationale of the "resume of
dependent devices" mechanism was incorrect to begin with and it's
best to remove it entirely.

Signed-off-by: Rafael J. Wysocki

ACPI: remove /proc/acpi/event from ACPI_BUTTON help

2013-10-15T22:31:47+00:00

Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface)
left /proc/acpi/event in the ACPI_BUTTON help in Kconfig, so
remove it from there.

[rjw: Changelog]
Signed-off-by: Krzysztof Mazur 
Signed-off-by: Rafael J. Wysocki

ACPI / power: Release resource_lock after acpi_power_get_state() return error

2013-10-15T22:26:42+00:00

In acpi_resume_power_resources() resource_lock should be released
when acpi_power_get_state() fails and before passing to next power
resource on the list.

Signed-off-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki

ACPI / PM / Documentation: Replace outdated project links and addresses

2013-10-11T11:22:43+00:00

Some links to projects web pages and e-mail addresses in ACPI/PM
documentation and Kconfig are outdated, so update them.

Signed-off-by: Rafael J. Wysocki