From 8d21d4c91efaed3eb60cc64d43889665a4bd7a36 Mon Sep 17 00:00:00 2001 From: "Chen, Gong" Date: Mon, 28 Jul 2014 02:50:59 -0400 Subject: APEI, GHES: Cleanup unnecessary function for lockless list We have a generic function to reverse a lockless list, kill homegrown copy. Signed-off-by: Chen, Gong Link: http://lkml.kernel.org/r/1406530260-26078-2-git-send-email-gong.chen@linux.intel.com Acked-by: Tony Luck Acked-by: Naoya Horiguchi [ Boris: correct commit msg ] Signed-off-by: Borislav Petkov --- drivers/acpi/apei/ghes.c | 18 ++---------------- 1 file changed, 2 insertions(+), 16 deletions(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index fc5f780bb61d..9dcc9158c8e2 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -738,20 +738,6 @@ static LIST_HEAD(ghes_nmi); static int ghes_panic_timeout __read_mostly = 30; -static struct llist_node *llist_nodes_reverse(struct llist_node *llnode) -{ - struct llist_node *next, *tail = NULL; - - while (llnode) { - next = llnode->next; - llnode->next = tail; - tail = llnode; - llnode = next; - } - - return tail; -} - static void ghes_proc_in_irq(struct irq_work *irq_work) { struct llist_node *llnode, *next; @@ -765,7 +751,7 @@ static void ghes_proc_in_irq(struct irq_work *irq_work) * Because the time order of estatus in list is reversed, * revert it back to proper order. */ - llnode = llist_nodes_reverse(llnode); + llnode = llist_reverse_order(llnode); while (llnode) { next = llnode->next; estatus_node = llist_entry(llnode, struct ghes_estatus_node, @@ -798,7 +784,7 @@ static void ghes_print_queued_estatus(void) * Because the time order of estatus in list is reversed, * revert it back to proper order. */ - llnode = llist_nodes_reverse(llnode); + llnode = llist_reverse_order(llnode); while (llnode) { estatus_node = llist_entry(llnode, struct ghes_estatus_node, llnode); -- cgit v1.2.3 From 8f7c31f6cd499877aa6b96decd31b406a6cd4ddf Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Mon, 29 Sep 2014 13:33:17 +0200 Subject: GHES: Make ghes_estatus_caches static It is used only in ghes.c. Signed-off-by: Borislav Petkov --- drivers/acpi/apei/ghes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 9dcc9158c8e2..1b6aa514848f 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -128,7 +128,7 @@ static DEFINE_SPINLOCK(ghes_ioremap_lock_irq); static struct gen_pool *ghes_estatus_pool; static unsigned long ghes_estatus_pool_size_request; -struct ghes_estatus_cache *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE]; +static struct ghes_estatus_cache *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE]; static atomic_t ghes_estatus_cache_alloced; static int ghes_ioremap_init(void) -- cgit v1.2.3 From 222584647f2821c4d68421c1d07c89b375d501b2 Mon Sep 17 00:00:00 2001 From: Adam Lee Date: Mon, 27 Oct 2014 13:55:45 +0800 Subject: ACPI / blacklist: blacklist Win8 OSI for Dell Vostro 3546 The wireless hotkey of Dell Vostro 3546 does not work with Win8 OSI. Due to insufficient documentation for the driver implementation, blacklist it as a workaround. Signed-off-by: Adam Lee Signed-off-by: Rafael J. Wysocki --- drivers/acpi/blacklist.c | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'drivers/acpi') diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c index ed122e17636e..7556e7c4a055 100644 --- a/drivers/acpi/blacklist.c +++ b/drivers/acpi/blacklist.c @@ -290,6 +290,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3446"), }, }, + { + .callback = dmi_disable_osi_win8, + .ident = "Dell Vostro 3546", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3546"), + }, + }, /* * BIOS invocation of _OSI(Linux) is almost always a BIOS bug. -- cgit v1.2.3 From 78579b7c7eb45f0e7ec5e9437087ed21749f9a9c Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 19 Nov 2014 01:44:11 +0100 Subject: ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up As reported by Dmitry, on some Chromebooks there are devices with corresponding ACPI objects and with unusual system wakeup configuration. Namely, they technically are wakeup-capable, but the wakeup is handled via a platform-specific out-of-band mechanism and the ACPI PM layer has no information on the wakeup capability. As a result, device_may_wakeup(dev) called from acpi_dev_suspend_late() returns 'true' for those devices, but the wakeup.flags.valid flag is unset for the corresponding ACPI device objects, so acpi_device_wakeup() reproducibly fails for them causing acpi_dev_suspend_late() to return an error code. The entire system suspend is then aborted and the machines in question cannot suspend at all. Address the problem by ignoring the device_may_wakeup(dev) return value in acpi_dev_suspend_late() if the ACPI companion of the device being handled has wakeup.flags.valid unset (in which case it is clear that the wakeup is supposed to be handled by other means). This fixes a regression introduced by commit a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain) as the affected systems could suspend and resume successfully before that commit. Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain) Reported-by: Dmitry Torokhov Reviewed-by: Dmitry Torokhov Cc: 3.13+ # 3.13+ Signed-off-by: Rafael J. Wysocki --- drivers/acpi/device_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 143ec6ea1468..7db193160766 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -878,7 +878,7 @@ int acpi_dev_suspend_late(struct device *dev) return 0; target_state = acpi_target_system_state(); - wakeup = device_may_wakeup(dev); + wakeup = device_may_wakeup(dev) && acpi_device_can_wakeup(adev); error = acpi_device_wakeup(adev, target_state, wakeup); if (wakeup && error) return error; -- cgit v1.2.3 From 35d0565b95547ec12d025dc9b1394f22968d113d Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Mon, 1 Dec 2014 02:09:18 +0100 Subject: ACPI / video: update condition to check if device is in _DOD list Commit 0b8db271f159 ("ACPI / video: check _DOD list when creating backlight devices") checks if the video device is in the bind devices list to decide if we should create backlight device for it, that causes problem for one Dell Latitude E6410, where none of the video output devices are properly bound due to the way how we did the comparing between its _ADR and the _DOD's values. Solve this problem by comparing the lower 12 bits of both the device's _ADR and the _DOD's values instead of relying on bind result. Fixes: 0b8db271f159 ("ACPI / video: check _DOD list when creating backlight devices") Reported-and-tested-by: Brian Norris Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki --- drivers/acpi/video.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 807a88a0f394..9d75ead2a1f9 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -1164,7 +1164,8 @@ static bool acpi_video_device_in_dod(struct acpi_video_device *device) return true; for (i = 0; i < video->attached_count; i++) { - if (video->attached_array[i].bind_info == device) + if ((video->attached_array[i].value.int_val & 0xfff) == + (device->device_id & 0xfff)) return true; } -- cgit v1.2.3