kernel/linux.git/drivers/acpi, branch v3.4.105

ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock

2014-12-01T10:02:22+00:00

commit 6726655dfdd2dc60c035c690d9f10cb69d7ea075 upstream. There is a following AB-BA dependency between cpu_hotplug.lock and cpuidle_lock: 1) cpu_hotplug.lock -> cpuidle_lock enable_nonboot_cpus() _cpu_up() cpu_hotplug_begin() LOCK(cpu_hotplug.lock) cpu_notify() ... acpi_processor_hotplug() cpuidle_pause_and_lock() LOCK(cpuidle_lock) 2) cpuidle_lock -> cpu_hotplug.lock acpi_os_execute_deferred() workqueue ... acpi_processor_cst_has_changed() cpuidle_pause_and_lock() LOCK(cpuidle_lock) get_online_cpus() LOCK(cpu_hotplug.lock) Fix this by reversing the order acpi_processor_cst_has_changed() does thigs -- let it first execute the protection against CPU hotplug by calling get_online_cpus() and obtain the cpuidle lock only after that (and perform the symmentric change when allowing CPUs hotplug again and dropping cpuidle lock). Spotted by lockdep. Signed-off-by: Jiri Kosina Signed-off-by: Rafael J. Wysocki Signed-off-by: Zefan Li

ACPI / battery: Retry to get battery information if failed during probing

2014-07-17T22:39:50+00:00

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream. Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails. [ backport to 3.14.5: removed second parameter in acpi_battery_update(), introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI / battery: Accelerate battery resume callback)] [naszar : backport to 3.14.5] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581 Reported-and-tested-by: naszar Cc: All applicable Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI video: ignore BIOS backlight value for HP dm4

2014-07-09T17:51:22+00:00

commit 771d09b3c4c45d4d534a83a68e6331b97fd82e15 upstream. On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot, completely dimming the screen. Ignore this initial value for this machine. Signed-off-by: Gustavo Maciel Dias Vieira Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings [wyj: Backported to 3.4: adjust context] Signed-off-by: Yijing Wang Signed-off-by: Greg Kroah-Hartman

ACPI video: ignore BIOS initial backlight value for HP 1000

2014-07-09T17:51:21+00:00

commit 4ef366c583d6180b1c951147869ee5a3038834f2 upstream. On HP 1000 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References:: https://bugs.launchpad.net/bugs/1167760 Signed-off-by: Alex Hung Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings Cc: Yijing Wang Signed-off-by: Greg Kroah-Hartman

ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist

2014-07-09T17:51:21+00:00

commit c8f6d8351ba8c89d5cd4c562552ec7ec29274e31 upstream. Like on UL30VT, the ACPI video driver can't control backlight correctly on Asus UL30A. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30A" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30A" rather than ACPI video driver. Signed-off-by: Bastian Triller Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings Cc: Yijing Wang Signed-off-by: Greg Kroah-Hartman

ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist

2014-07-09T17:51:21+00:00

commit d0c2ce16bec0afa6013b4c5220ca4c9c67210215 upstream. The ACPI video driver can't control backlight correctly on Asus UL30VT. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30VT" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30VT" rather than ACPI video driver. References: https://bugzilla.kernel.org/show_bug.cgi?id=32592 Reported-by: Alex Williamson Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings Cc: Yijing Wang Signed-off-by: Greg Kroah-Hartman

acpi/video_detect: blacklist samsung x360

2014-07-09T17:51:21+00:00

commit 084940d5b101e9ca91a689eb5048151b14076839 upstream. On Samsung X360, the BIOS will set a flag (VDRV) if the generic ACPI backlight device is used. This flag will definitively break the backlight interface (even the vendor interface) untill next reboot. It's why we should prevent video.ko from being used here and we can't rely on a later call to acpi_video_unregister(). Signed-off-by: Corentin Chary Signed-off-by: Matthew Garrett Signed-off-by: Ben Hutchings Cc: Yijing Wang Signed-off-by: Greg Kroah-Hartman

ACPI: Fix conflict between customized DSDT and DSDT local copy

2014-07-01T03:01:32+00:00

commit 73577d1df8e1f31f6b1a5eebcdbc334eb0330e47 upstream. This patch fixes the following issue: If DSDT is customized, no local DSDT copy is needed. References: https://bugzilla.kernel.org/show_bug.cgi?id=69711 Signed-off-by: Enrico Etxe Arte Signed-off-by: Lv Zheng [rjw: Subject] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX

2014-06-07T23:02:03+00:00

commit f6e6e1b9fee88c90586787b71dc49bb3ce62bb89 upstream. Without this this EEE PC exports a non working WMI interface, with this it exports a working "good old" eeepc_laptop interface, fixing brightness control not working as well as rfkill being stuck in a permanent wireless blocked state. This is not an ideal way to fix this, but various attempts to fix this otherwise have failed, see: References: https://bugzilla.redhat.com/show_bug.cgi?id=1067181 Reported-and-tested-by: lou.cardone@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / processor: Rework processor throttling with work_on_cpu()

2014-03-11T23:10:01+00:00

commit f3ca4164529b875374c410193bbbac0ee960895f upstream. acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make sure that the (struct acpi_processor)->acpi_processor_set_throttling() callback will run on the right CPU. However, the function may be called from a worker thread already bound to a different CPU in which case that won't work. Make acpi_processor_set_throttling() use work_on_cpu() as appropriate instead of abusing set_cpus_allowed_ptr(). Reported-and-tested-by: Jiri Olsa Signed-off-by: Lan Tianyu [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman