From: Greg Kroah-Hartman Date: Tue, 26 Nov 2013 03:48:32 +0000 (-0800) Subject: 3.11-stable patches X-Git-Tag: v3.11.10~27^2~1 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7667e476efd229a2b4f33554c18fc2f3e367fe36;p=thirdparty%2Fkernel%2Fstable-queue.git 3.11-stable patches added patches: acpi-ec-ensure-lock-is-acquired-before-accessing-ec-struct-members.patch acpi-hotplug-do-not-execute-insert-in-progress-_ost.patch acpi-hotplug-fix-handle_root_bridge_removal.patch acpi-video-quirk-initial-backlight-level-0.patch --- diff --git a/queue-3.11/acpi-ec-ensure-lock-is-acquired-before-accessing-ec-struct-members.patch b/queue-3.11/acpi-ec-ensure-lock-is-acquired-before-accessing-ec-struct-members.patch new file mode 100644 index 00000000000..ec075c1d926 --- /dev/null +++ b/queue-3.11/acpi-ec-ensure-lock-is-acquired-before-accessing-ec-struct-members.patch @@ -0,0 +1,43 @@ +From 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb Mon Sep 17 00:00:00 2001 +From: Puneet Kumar +Date: Fri, 15 Nov 2013 11:41:29 -0800 +Subject: ACPI / EC: Ensure lock is acquired before accessing ec struct members + +From: Puneet Kumar + +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 + +--- + drivers/acpi/ec.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/ec.c ++++ b/drivers/acpi/ec.c +@@ -175,9 +175,10 @@ static void start_transaction(struct acp + static void advance_transaction(struct acpi_ec *ec, u8 status) + { + unsigned long flags; +- struct transaction *t = ec->curr; ++ struct transaction *t; + + spin_lock_irqsave(&ec->lock, flags); ++ t = ec->curr; + if (!t) + goto unlock; + if (t->wlen > t->wi) { diff --git a/queue-3.11/acpi-hotplug-do-not-execute-insert-in-progress-_ost.patch b/queue-3.11/acpi-hotplug-do-not-execute-insert-in-progress-_ost.patch new file mode 100644 index 00000000000..539265fae12 --- /dev/null +++ b/queue-3.11/acpi-hotplug-do-not-execute-insert-in-progress-_ost.patch @@ -0,0 +1,39 @@ +From 176a88d79d6b5aebabaff16734e8b3107efcaaad Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 7 Nov 2013 01:42:17 +0100 +Subject: ACPI / hotplug: Do not execute "insert in progress" _OST + +From: "Rafael J. Wysocki" + +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 + +--- + drivers/acpi/scan.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/acpi/scan.c ++++ b/drivers/acpi/scan.c +@@ -359,8 +359,6 @@ static void acpi_scan_bus_device_check(a + goto out; + } + } +- acpi_evaluate_hotplug_ost(handle, ost_source, +- ACPI_OST_SC_INSERT_IN_PROGRESS, NULL); + error = acpi_bus_scan(handle); + if (error) { + acpi_handle_warn(handle, "Namespace scan failure\n"); diff --git a/queue-3.11/acpi-hotplug-fix-handle_root_bridge_removal.patch b/queue-3.11/acpi-hotplug-fix-handle_root_bridge_removal.patch new file mode 100644 index 00000000000..a4e2cdcfe71 --- /dev/null +++ b/queue-3.11/acpi-hotplug-fix-handle_root_bridge_removal.patch @@ -0,0 +1,47 @@ +From 2441191a19039002b2c454a261fb45986df15184 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 7 Nov 2013 01:41:27 +0100 +Subject: ACPI / hotplug: Fix handle_root_bridge_removal() + +From: "Rafael J. Wysocki" + +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 + +--- + drivers/acpi/pci_root.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/pci_root.c ++++ b/drivers/acpi/pci_root.c +@@ -611,9 +611,12 @@ static void handle_root_bridge_removal(s + ej_event->device = device; + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST; + ++ get_device(&device->dev); + status = acpi_os_hotplug_execute(acpi_bus_hot_remove_device, ej_event); +- if (ACPI_FAILURE(status)) ++ if (ACPI_FAILURE(status)) { ++ put_device(&device->dev); + kfree(ej_event); ++ } + } + + static void _handle_hotplug_event_root(struct work_struct *work) diff --git a/queue-3.11/acpi-video-quirk-initial-backlight-level-0.patch b/queue-3.11/acpi-video-quirk-initial-backlight-level-0.patch new file mode 100644 index 00000000000..c076ef7fdcd --- /dev/null +++ b/queue-3.11/acpi-video-quirk-initial-backlight-level-0.patch @@ -0,0 +1,44 @@ +From 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 Mon Sep 17 00:00:00 2001 +From: Aaron Lu +Date: Wed, 6 Nov 2013 09:07:10 +0800 +Subject: ACPI / video: Quirk initial backlight level 0 + +From: Aaron Lu + +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 + +--- + drivers/acpi/video.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/acpi/video.c ++++ b/drivers/acpi/video.c +@@ -848,7 +848,7 @@ acpi_video_init_brightness(struct acpi_v + for (i = 2; i < br->count; i++) + if (level_old == br->levels[i]) + break; +- if (i == br->count) ++ if (i == br->count || !level) + level = max_level; + } + diff --git a/queue-3.11/series b/queue-3.11/series index 4b781e1e3af..dcc1af38dc2 100644 --- a/queue-3.11/series +++ b/queue-3.11/series @@ -19,3 +19,7 @@ sched-idle-fix-the-idle-polling-state-logic.patch pci-allow-pcie-capability-link-related-register-access-for-switches.patch pci-remove-pcie-capability-version-checks.patch pci-support-pcie-capability-slot-registers-only-for-ports-with-slots.patch +acpi-ec-ensure-lock-is-acquired-before-accessing-ec-struct-members.patch +acpi-video-quirk-initial-backlight-level-0.patch +acpi-hotplug-fix-handle_root_bridge_removal.patch +acpi-hotplug-do-not-execute-insert-in-progress-_ost.patch