From: Greg Kroah-Hartman Date: Thu, 20 Mar 2014 01:16:14 +0000 (+0000) Subject: 3.13-stable patches X-Git-Tag: v3.4.84~37 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d10262add48d64f55130485fd439716e06e3b196;p=thirdparty%2Fkernel%2Fstable-queue.git 3.13-stable patches added patches: acpi-ec-clear-stale-ec-events-on-samsung-systems.patch acpi-resources-ignore-invalid-acpi-device-resources.patch arm-7991-1-sa1100-fix-compile-problem-on-collie.patch arm-fix-nommu-kallsyms-symbol-filtering.patch cpuset-fix-a-locking-issue-in-cpuset_migrate_mm.patch cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch drm-armada-fix-use-of-kfifo_put.patch genirq-remove-racy-waitqueue_active-check.patch regulator-core-replace-direct-ops-enable-usage.patch revert-usbnet-ax88179_178a-enable-tso-if-usb-host-supports-sg-dma.patch revert-xhci-1.0-limit-arbitrarily-aligned-scatter-gather.patch usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch x86-ignore-nmis-that-come-in-during-early-boot.patch x86_pkg_temp_thermal-do-not-expose-as-a-hwmon-device.patch --- diff --git a/queue-3.13/acpi-ec-clear-stale-ec-events-on-samsung-systems.patch b/queue-3.13/acpi-ec-clear-stale-ec-events-on-samsung-systems.patch new file mode 100644 index 00000000000..13531dd5b5c --- /dev/null +++ b/queue-3.13/acpi-ec-clear-stale-ec-events-on-samsung-systems.patch @@ -0,0 +1,177 @@ +From ad332c8a45330d170bb38b95209de449b31cd1b4 Mon Sep 17 00:00:00 2001 +From: Kieran Clancy +Date: Sat, 1 Mar 2014 00:42:28 +1030 +Subject: ACPI / EC: Clear stale EC events on Samsung systems + +From: Kieran Clancy + +commit ad332c8a45330d170bb38b95209de449b31cd1b4 upstream. + +A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) +continue to log events during sleep (lid open/close, AC plug/unplug, +battery level change), which accumulate in the EC until a buffer fills. +After the buffer is full (tests suggest it holds 8 events), GPEs stop +being triggered for new events. This state persists on wake or even on +power cycle, and prevents new events from being registered until the EC +is manually polled. + +This is the root cause of a number of bugs, including AC not being +detected properly, lid close not triggering suspend, and low ambient +light not triggering the keyboard backlight. The bug also seemed to be +responsible for performance issues on at least one user's machine. + +Juan Manuel Cabo found the cause of bug and the workaround of polling +the EC manually on wake. + +The loop which clears the stale events is based on an earlier patch by +Lan Tianyu (see referenced attachment). + +This patch: + - Adds a function acpi_ec_clear() which polls the EC for stale _Q + events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is + logged if this limit is reached. + - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI + system vendor is Samsung. This check could be replaced by several + more specific DMI vendor/product pairs, but it's likely that the bug + affects more Samsung products than just the five series mentioned + above. Further, it should not be harmful to run acpi_ec_clear() on + systems without the bug; it will return immediately after finding no + data waiting. + - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() + - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() + +References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 +References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 +References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 +References: https://bugzilla.kernel.org/attachment.cgi?id=126801 +Suggested-by: Juan Manuel Cabo +Signed-off-by: Kieran Clancy +Reviewed-by: Lan Tianyu +Reviewed-by: Dennis Jansen +Tested-by: Kieran Clancy +Tested-by: Juan Manuel Cabo +Tested-by: Dennis Jansen +Tested-by: Maurizio D'Addona +Tested-by: San Zamoyski +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/ec.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 64 insertions(+) + +--- a/drivers/acpi/ec.c ++++ b/drivers/acpi/ec.c +@@ -68,6 +68,8 @@ enum ec_command { + #define ACPI_EC_DELAY 500 /* Wait 500ms max. during EC ops */ + #define ACPI_EC_UDELAY_GLK 1000 /* Wait 1ms max. to get global lock */ + #define ACPI_EC_MSI_UDELAY 550 /* Wait 550us for MSI EC */ ++#define ACPI_EC_CLEAR_MAX 100 /* Maximum number of events to query ++ * when trying to clear the EC */ + + enum { + EC_FLAGS_QUERY_PENDING, /* Query is pending */ +@@ -121,6 +123,7 @@ EXPORT_SYMBOL(first_ec); + static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */ + static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */ + static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan */ ++static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */ + + /* -------------------------------------------------------------------------- + Transaction Management +@@ -466,6 +469,29 @@ acpi_handle ec_get_handle(void) + + EXPORT_SYMBOL(ec_get_handle); + ++static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data); ++ ++/* ++ * Clears stale _Q events that might have accumulated in the EC. ++ * Run with locked ec mutex. ++ */ ++static void acpi_ec_clear(struct acpi_ec *ec) ++{ ++ int i, status; ++ u8 value = 0; ++ ++ for (i = 0; i < ACPI_EC_CLEAR_MAX; i++) { ++ status = acpi_ec_query_unlocked(ec, &value); ++ if (status || !value) ++ break; ++ } ++ ++ if (unlikely(i == ACPI_EC_CLEAR_MAX)) ++ pr_warn("Warning: Maximum of %d stale EC events cleared\n", i); ++ else ++ pr_info("%d stale EC events cleared\n", i); ++} ++ + void acpi_ec_block_transactions(void) + { + struct acpi_ec *ec = first_ec; +@@ -489,6 +515,10 @@ void acpi_ec_unblock_transactions(void) + mutex_lock(&ec->mutex); + /* Allow transactions to be carried out again */ + clear_bit(EC_FLAGS_BLOCKED, &ec->flags); ++ ++ if (EC_FLAGS_CLEAR_ON_RESUME) ++ acpi_ec_clear(ec); ++ + mutex_unlock(&ec->mutex); + } + +@@ -847,6 +877,13 @@ static int acpi_ec_add(struct acpi_devic + + /* EC is fully operational, allow queries */ + clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags); ++ ++ /* Clear stale _Q events if hardware might require that */ ++ if (EC_FLAGS_CLEAR_ON_RESUME) { ++ mutex_lock(&ec->mutex); ++ acpi_ec_clear(ec); ++ mutex_unlock(&ec->mutex); ++ } + return ret; + } + +@@ -948,6 +985,30 @@ static int ec_enlarge_storm_threshold(co + return 0; + } + ++/* ++ * On some hardware it is necessary to clear events accumulated by the EC during ++ * sleep. These ECs stop reporting GPEs until they are manually polled, if too ++ * many events are accumulated. (e.g. Samsung Series 5/9 notebooks) ++ * ++ * https://bugzilla.kernel.org/show_bug.cgi?id=44161 ++ * ++ * Ideally, the EC should also be instructed NOT to accumulate events during ++ * sleep (which Windows seems to do somehow), but the interface to control this ++ * behaviour is not known at this time. ++ * ++ * Models known to be affected are Samsung 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx, ++ * however it is very likely that other Samsung models are affected. ++ * ++ * On systems which don't accumulate _Q events during sleep, this extra check ++ * should be harmless. ++ */ ++static int ec_clear_on_resume(const struct dmi_system_id *id) ++{ ++ pr_debug("Detected system needing EC poll on resume.\n"); ++ EC_FLAGS_CLEAR_ON_RESUME = 1; ++ return 0; ++} ++ + static struct dmi_system_id ec_dmi_table[] __initdata = { + { + ec_skip_dsdt_scan, "Compal JFL92", { +@@ -991,6 +1052,9 @@ static struct dmi_system_id ec_dmi_table + ec_validate_ecdt, "ASUS hardware", { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL}, ++ { ++ ec_clear_on_resume, "Samsung hardware", { ++ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL}, + {}, + }; + diff --git a/queue-3.13/acpi-resources-ignore-invalid-acpi-device-resources.patch b/queue-3.13/acpi-resources-ignore-invalid-acpi-device-resources.patch new file mode 100644 index 00000000000..d98db2ba5ad --- /dev/null +++ b/queue-3.13/acpi-resources-ignore-invalid-acpi-device-resources.patch @@ -0,0 +1,71 @@ +From b355cee88e3b1a193f0e9a81db810f6f83ad728b Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Thu, 27 Feb 2014 11:37:15 +0800 +Subject: ACPI / resources: ignore invalid ACPI device resources + +From: Zhang Rui + +commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream. + +ACPI table may export resource entry with 0 length. +But the current code interprets this kind of resource in a wrong way. +It will create a resource structure with +res->end = acpi_resource->start + acpi_resource->len - 1; + +This patch fixes a problem on my machine that a platform device fails +to be created because one of its ACPI IO resource entry (start = 0, +end = 0, length = 0) is translated into a generic resource with +start = 0, end = 0xffffffff. + +Signed-off-by: Zhang Rui +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/resource.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -77,18 +77,24 @@ bool acpi_dev_resource_memory(struct acp + switch (ares->type) { + case ACPI_RESOURCE_TYPE_MEMORY24: + memory24 = &ares->data.memory24; ++ if (!memory24->address_length) ++ return false; + acpi_dev_get_memresource(res, memory24->minimum, + memory24->address_length, + memory24->write_protect); + break; + case ACPI_RESOURCE_TYPE_MEMORY32: + memory32 = &ares->data.memory32; ++ if (!memory32->address_length) ++ return false; + acpi_dev_get_memresource(res, memory32->minimum, + memory32->address_length, + memory32->write_protect); + break; + case ACPI_RESOURCE_TYPE_FIXED_MEMORY32: + fixed_memory32 = &ares->data.fixed_memory32; ++ if (!fixed_memory32->address_length) ++ return false; + acpi_dev_get_memresource(res, fixed_memory32->address, + fixed_memory32->address_length, + fixed_memory32->write_protect); +@@ -144,12 +150,16 @@ bool acpi_dev_resource_io(struct acpi_re + switch (ares->type) { + case ACPI_RESOURCE_TYPE_IO: + io = &ares->data.io; ++ if (!io->address_length) ++ return false; + acpi_dev_get_ioresource(res, io->minimum, + io->address_length, + io->io_decode); + break; + case ACPI_RESOURCE_TYPE_FIXED_IO: + fixed_io = &ares->data.fixed_io; ++ if (!fixed_io->address_length) ++ return false; + acpi_dev_get_ioresource(res, fixed_io->address, + fixed_io->address_length, + ACPI_DECODE_10); diff --git a/queue-3.13/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch b/queue-3.13/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch new file mode 100644 index 00000000000..82f0ad6bf4f --- /dev/null +++ b/queue-3.13/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch @@ -0,0 +1,44 @@ +From 052450fdc55894a39fbae93d9bbe43947956f663 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 25 Feb 2014 22:41:41 +0100 +Subject: ARM: 7991/1: sa1100: fix compile problem on Collie + +From: Linus Walleij + +commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream. + +Due to a problem in the MFD Kconfig it was not possible to +compile the UCB battery driver for the Collie SA1100 system, +in turn making it impossible to compile in the battery driver. +(See patch "mfd: include all drivers in subsystem menu".) + +After fixing the MFD Kconfig (separate patch) a compile error +appears in the Collie battery driver due to the +implicitly requiring through +via prior to commit +40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface". + +Fix this up by including the required header into +. + +Cc: Andrea Adami +Cc: Dmitry Eremin-Solenikov +Signed-off-by: Linus Walleij +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-sa1100/include/mach/collie.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm/mach-sa1100/include/mach/collie.h ++++ b/arch/arm/mach-sa1100/include/mach/collie.h +@@ -13,6 +13,8 @@ + #ifndef __ASM_ARCH_COLLIE_H + #define __ASM_ARCH_COLLIE_H + ++#include "hardware.h" /* Gives GPIO_MAX */ ++ + extern void locomolcd_power(int on); + + #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1) diff --git a/queue-3.13/arm-fix-nommu-kallsyms-symbol-filtering.patch b/queue-3.13/arm-fix-nommu-kallsyms-symbol-filtering.patch new file mode 100644 index 00000000000..1a109cb7c97 --- /dev/null +++ b/queue-3.13/arm-fix-nommu-kallsyms-symbol-filtering.patch @@ -0,0 +1,76 @@ +From 006fa2599bf0daf107cbb7a8a99fcfb9a998a169 Mon Sep 17 00:00:00 2001 +From: Russell King +Date: Wed, 26 Feb 2014 19:40:46 +0000 +Subject: ARM: fix noMMU kallsyms symbol filtering + +From: Russell King + +commit 006fa2599bf0daf107cbb7a8a99fcfb9a998a169 upstream. + +With noMMU, CONFIG_PAGE_OFFSET was not being set correctly. As there's +no MMU, PAGE_OFFSET should be equal to PHYS_OFFSET in all cases. This +commit makes that explicit. + +Since we do this, we don't need to mess around in asm/memory.h with +ifdefs to sort this out, so let's get rid of that, and there's no point +offering the "Memory split" option for noMMU as that's meaningless +there. + +Fixes: b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs") +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/Kconfig | 2 ++ + arch/arm/include/asm/memory.h | 9 +++------ + 2 files changed, 5 insertions(+), 6 deletions(-) + +--- a/arch/arm/Kconfig ++++ b/arch/arm/Kconfig +@@ -1543,6 +1543,7 @@ config BL_SWITCHER_DUMMY_IF + + choice + prompt "Memory split" ++ depends on MMU + default VMSPLIT_3G + help + Select the desired split between kernel and user memory. +@@ -1560,6 +1561,7 @@ endchoice + + config PAGE_OFFSET + hex ++ default PHYS_OFFSET if !MMU + default 0x40000000 if VMSPLIT_1G + default 0x80000000 if VMSPLIT_2G + default 0xC0000000 +--- a/arch/arm/include/asm/memory.h ++++ b/arch/arm/include/asm/memory.h +@@ -30,14 +30,15 @@ + */ + #define UL(x) _AC(x, UL) + ++/* PAGE_OFFSET - the virtual address of the start of the kernel image */ ++#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET) ++ + #ifdef CONFIG_MMU + + /* +- * PAGE_OFFSET - the virtual address of the start of the kernel image + * TASK_SIZE - the maximum size of a user space task. + * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area + */ +-#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET) + #define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M)) + #define TASK_UNMAPPED_BASE ALIGN(TASK_SIZE / 3, SZ_16M) + +@@ -104,10 +105,6 @@ + #define END_MEM (UL(CONFIG_DRAM_BASE) + CONFIG_DRAM_SIZE) + #endif + +-#ifndef PAGE_OFFSET +-#define PAGE_OFFSET PLAT_PHYS_OFFSET +-#endif +- + /* + * The module can be at any place in ram in nommu mode. + */ diff --git a/queue-3.13/cpuset-fix-a-locking-issue-in-cpuset_migrate_mm.patch b/queue-3.13/cpuset-fix-a-locking-issue-in-cpuset_migrate_mm.patch new file mode 100644 index 00000000000..7afe9ec2b71 --- /dev/null +++ b/queue-3.13/cpuset-fix-a-locking-issue-in-cpuset_migrate_mm.patch @@ -0,0 +1,75 @@ +From 4729583006772b9530404bc1bb7c3aa4a10ffd4d Mon Sep 17 00:00:00 2001 +From: Li Zefan +Date: Thu, 27 Feb 2014 18:19:03 +0800 +Subject: cpuset: fix a locking issue in cpuset_migrate_mm() + +From: Li Zefan + +commit 4729583006772b9530404bc1bb7c3aa4a10ffd4d upstream. + +I can trigger a lockdep warning: + + # mount -t cgroup -o cpuset xxx /cgroup + # mkdir /cgroup/cpuset + # mkdir /cgroup/tmp + # echo 0 > /cgroup/tmp/cpuset.cpus + # echo 0 > /cgroup/tmp/cpuset.mems + # echo 1 > /cgroup/tmp/cpuset.memory_migrate + # echo $$ > /cgroup/tmp/tasks + # echo 1 > /cgruop/tmp/cpuset.mems + + =============================== + [ INFO: suspicious RCU usage. ] + 3.14.0-rc1-0.1-default+ #32 Not tainted + ------------------------------- + include/linux/cgroup.h:682 suspicious rcu_dereference_check() usage! + ... + [] dump_stack+0x72/0x86 + [] lockdep_rcu_suspicious+0x101/0x140 + [] cpuset_migrate_mm+0xb1/0xe0 + ... + +We used to hold cgroup_mutex when calling cpuset_migrate_mm(), but now +we hold cpuset_mutex, which causes task_css() to complain. + +This is not a false-positive but a real issue. + +Holding cpuset_mutex won't prevent a task from migrating to another +cpuset, and it won't prevent the original task->cgroup from destroying +during this change. + +Fixes: 5d21cc2db040 (cpuset: replace cgroup_mutex locking with cpuset internal locking) +Signed-off-by: Li Zefan +Sigend-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cpuset.c | 8 ++------ + 1 file changed, 2 insertions(+), 6 deletions(-) + +--- a/kernel/cpuset.c ++++ b/kernel/cpuset.c +@@ -974,12 +974,6 @@ static int update_cpumask(struct cpuset + * Temporarilly set tasks mems_allowed to target nodes of migration, + * so that the migration code can allocate pages on these nodes. + * +- * Call holding cpuset_mutex, so current's cpuset won't change +- * during this call, as manage_mutex holds off any cpuset_attach() +- * calls. Therefore we don't need to take task_lock around the +- * call to guarantee_online_mems(), as we know no one is changing +- * our task's cpuset. +- * + * While the mm_struct we are migrating is typically from some + * other task, the task_struct mems_allowed that we are hacking + * is for our current task, which must allocate new pages for that +@@ -996,8 +990,10 @@ static void cpuset_migrate_mm(struct mm_ + + do_migrate_pages(mm, from, to, MPOL_MF_MOVE_ALL); + ++ rcu_read_lock(); + mems_cs = effective_nodemask_cpuset(task_cs(tsk)); + guarantee_online_mems(mems_cs, &tsk->mems_allowed); ++ rcu_read_unlock(); + } + + /* diff --git a/queue-3.13/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch b/queue-3.13/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch new file mode 100644 index 00000000000..1c04a3ac298 --- /dev/null +++ b/queue-3.13/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch @@ -0,0 +1,33 @@ +From 99afb0fd5f05aac467ffa85c36778fec4396209b Mon Sep 17 00:00:00 2001 +From: Li Zefan +Date: Thu, 27 Feb 2014 18:19:36 +0800 +Subject: cpuset: fix a race condition in __cpuset_node_allowed_softwall() + +From: Li Zefan + +commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream. + +It's not safe to access task's cpuset after releasing task_lock(). +Holding callback_mutex won't help. + +Signed-off-by: Li Zefan +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cpuset.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/cpuset.c ++++ b/kernel/cpuset.c +@@ -2507,9 +2507,9 @@ int __cpuset_node_allowed_softwall(int n + + task_lock(current); + cs = nearest_hardwall_ancestor(task_cs(current)); ++ allowed = node_isset(node, cs->mems_allowed); + task_unlock(current); + +- allowed = node_isset(node, cs->mems_allowed); + mutex_unlock(&callback_mutex); + return allowed; + } diff --git a/queue-3.13/drm-armada-fix-use-of-kfifo_put.patch b/queue-3.13/drm-armada-fix-use-of-kfifo_put.patch new file mode 100644 index 00000000000..3ee58c34aa8 --- /dev/null +++ b/queue-3.13/drm-armada-fix-use-of-kfifo_put.patch @@ -0,0 +1,39 @@ +From d13c46c67e546bb1dc1c4dc7c43e388d0119276b Mon Sep 17 00:00:00 2001 +From: Russell King +Date: Mon, 3 Mar 2014 14:49:51 +0000 +Subject: DRM: armada: fix use of kfifo_put() + +From: Russell King + +commit d13c46c67e546bb1dc1c4dc7c43e388d0119276b upstream. + +The kfifo_put() API changed in 498d319bb512 (kfifo API type safety) +which now results in the wrong pointer being added to the kfifo ring, +which then causes an oops. Fix this. + +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/armada/armada_drv.c | 10 +--------- + 1 file changed, 1 insertion(+), 9 deletions(-) + +--- a/drivers/gpu/drm/armada/armada_drv.c ++++ b/drivers/gpu/drm/armada/armada_drv.c +@@ -68,15 +68,7 @@ void __armada_drm_queue_unref_work(struc + { + struct armada_private *priv = dev->dev_private; + +- /* +- * Yes, we really must jump through these hoops just to store a +- * _pointer_ to something into the kfifo. This is utterly insane +- * and idiotic, because it kfifo requires the _data_ pointed to by +- * the pointer const, not the pointer itself. Not only that, but +- * you have to pass a pointer _to_ the pointer you want stored. +- */ +- const struct drm_framebuffer *silly_api_alert = fb; +- WARN_ON(!kfifo_put(&priv->fb_unref, &silly_api_alert)); ++ WARN_ON(!kfifo_put(&priv->fb_unref, fb)); + schedule_work(&priv->fb_unref_work); + } + diff --git a/queue-3.13/genirq-remove-racy-waitqueue_active-check.patch b/queue-3.13/genirq-remove-racy-waitqueue_active-check.patch new file mode 100644 index 00000000000..cac8443aca1 --- /dev/null +++ b/queue-3.13/genirq-remove-racy-waitqueue_active-check.patch @@ -0,0 +1,61 @@ +From c685689fd24d310343ac33942e9a54a974ae9c43 Mon Sep 17 00:00:00 2001 +From: Chuansheng Liu +Date: Mon, 24 Feb 2014 11:29:50 +0800 +Subject: genirq: Remove racy waitqueue_active check + +From: Chuansheng Liu + +commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream. + +We hit one rare case below: + +T1 calling disable_irq(), but hanging at synchronize_irq() +always; +The corresponding irq thread is in sleeping state; +And all CPUs are in idle state; + +After analysis, we found there is one possible scenerio which +causes T1 is waiting there forever: +CPU0 CPU1 + synchronize_irq() + wait_event() + spin_lock() + atomic_dec_and_test(&threads_active) + insert the __wait into queue + spin_unlock() + if(waitqueue_active) + atomic_read(&threads_active) + wake_up() + +Here after inserted the __wait into queue on CPU0, and before +test if queue is empty on CPU1, there is no barrier, it maybe +cause it is not visible for CPU1 immediately, although CPU0 has +updated the queue list. +It is similar for CPU0 atomic_read() threads_active also. + +So we'd need one smp_mb() before waitqueue_active.that, but removing +the waitqueue_active() check solves it as wel l and it makes +things simple and clear. + +Signed-off-by: Chuansheng Liu +Cc: Xiaoming Wang +Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/manage.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/irq/manage.c ++++ b/kernel/irq/manage.c +@@ -802,8 +802,7 @@ static irqreturn_t irq_thread_fn(struct + + static void wake_threads_waitq(struct irq_desc *desc) + { +- if (atomic_dec_and_test(&desc->threads_active) && +- waitqueue_active(&desc->wait_for_threads)) ++ if (atomic_dec_and_test(&desc->threads_active)) + wake_up(&desc->wait_for_threads); + } + diff --git a/queue-3.13/regulator-core-replace-direct-ops-enable-usage.patch b/queue-3.13/regulator-core-replace-direct-ops-enable-usage.patch new file mode 100644 index 00000000000..e9de30672f4 --- /dev/null +++ b/queue-3.13/regulator-core-replace-direct-ops-enable-usage.patch @@ -0,0 +1,67 @@ +From 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b Mon Sep 17 00:00:00 2001 +From: Markus Pargmann +Date: Thu, 20 Feb 2014 17:36:03 +0100 +Subject: regulator: core: Replace direct ops->enable usage + +From: Markus Pargmann + +commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream. + +There are some direct ops->enable in the regulator core driver. This is +a potential issue as the function _regulator_do_enable() handles gpio +regulators and the normal ops->enable calls. These gpio regulators are +simply ignored when ops->enable is called directly. + +One possible bug is that boot-on and always-on gpio regulators are not +enabled on registration. + +This patch replaces all ops->enable calls by _regulator_do_enable. + +[Handle missing enable operations -- broonie] + +Signed-off-by: Markus Pargmann +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/regulator/core.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/regulator/core.c ++++ b/drivers/regulator/core.c +@@ -953,6 +953,8 @@ static int machine_constraints_current(s + return 0; + } + ++static int _regulator_do_enable(struct regulator_dev *rdev); ++ + /** + * set_machine_constraints - sets regulator constraints + * @rdev: regulator source +@@ -1013,10 +1015,9 @@ static int set_machine_constraints(struc + /* If the constraints say the regulator should be on at this point + * and we have control then make sure it is enabled. + */ +- if ((rdev->constraints->always_on || rdev->constraints->boot_on) && +- ops->enable) { +- ret = ops->enable(rdev); +- if (ret < 0) { ++ if (rdev->constraints->always_on || rdev->constraints->boot_on) { ++ ret = _regulator_do_enable(rdev); ++ if (ret < 0 && ret != -EINVAL) { + rdev_err(rdev, "failed to enable\n"); + goto out; + } +@@ -3633,9 +3634,8 @@ int regulator_suspend_finish(void) + struct regulator_ops *ops = rdev->desc->ops; + + mutex_lock(&rdev->mutex); +- if ((rdev->use_count > 0 || rdev->constraints->always_on) && +- ops->enable) { +- error = ops->enable(rdev); ++ if (rdev->use_count > 0 || rdev->constraints->always_on) { ++ error = _regulator_do_enable(rdev); + if (error) + ret = error; + } else { diff --git a/queue-3.13/revert-usbnet-ax88179_178a-enable-tso-if-usb-host-supports-sg-dma.patch b/queue-3.13/revert-usbnet-ax88179_178a-enable-tso-if-usb-host-supports-sg-dma.patch new file mode 100644 index 00000000000..219a2faa8db --- /dev/null +++ b/queue-3.13/revert-usbnet-ax88179_178a-enable-tso-if-usb-host-supports-sg-dma.patch @@ -0,0 +1,57 @@ +From 469d417b68958a064c09e7875646c97c6e783dfc Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Fri, 7 Mar 2014 17:06:58 +0200 +Subject: Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma" + +From: Mathias Nyman + +commit 469d417b68958a064c09e7875646c97c6e783dfc upstream. + +This reverts commit 3804fad45411b48233b48003e33a78f290d227c8. + +This commit, together with commit 247bf557273dd775505fb9240d2d152f4f20d304 +"xhci 1.0: Limit arbitrarily-aligned scatter gather." were +origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices +working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer +buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass +storage devices to fail more frequently. + +USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically, +the TD fragment rules could have caused an occasional disk glitch. +Now the devices *will* fail, instead of theoretically failing. +>From a user perspective, this looks like a regression; the USB device obviously +fails on 3.14-rc1, and may sometimes silently fail on prior kernels. + +The proper soluition is to implement the TD fragment rules for xHCI 1.0 hosts, +but for now, revert this patch until scatter gather can be properly supported. + +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/usb/ax88179_178a.c | 8 -------- + 1 file changed, 8 deletions(-) + +--- a/drivers/net/usb/ax88179_178a.c ++++ b/drivers/net/usb/ax88179_178a.c +@@ -1030,20 +1030,12 @@ static int ax88179_bind(struct usbnet *d + dev->mii.phy_id = 0x03; + dev->mii.supports_gmii = 1; + +- if (usb_device_no_sg_constraint(dev->udev)) +- dev->can_dma_sg = 1; +- + dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | + NETIF_F_RXCSUM; + + dev->net->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | + NETIF_F_RXCSUM; + +- if (dev->can_dma_sg) { +- dev->net->features |= NETIF_F_SG | NETIF_F_TSO; +- dev->net->hw_features |= NETIF_F_SG | NETIF_F_TSO; +- } +- + /* Enable checksum offload */ + *tmp = AX_RXCOE_IP | AX_RXCOE_TCP | AX_RXCOE_UDP | + AX_RXCOE_TCPV6 | AX_RXCOE_UDPV6; diff --git a/queue-3.13/revert-xhci-1.0-limit-arbitrarily-aligned-scatter-gather.patch b/queue-3.13/revert-xhci-1.0-limit-arbitrarily-aligned-scatter-gather.patch new file mode 100644 index 00000000000..f2a398a8563 --- /dev/null +++ b/queue-3.13/revert-xhci-1.0-limit-arbitrarily-aligned-scatter-gather.patch @@ -0,0 +1,72 @@ +From e2ed511400d41e0d136089d5a55ceab57c6a2426 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Fri, 7 Mar 2014 17:06:57 +0200 +Subject: Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather." + +From: Mathias Nyman + +commit e2ed511400d41e0d136089d5a55ceab57c6a2426 upstream. + +This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304. + +This commit, together with commit 3804fad45411b48233b48003e33a78f290d227c8 +"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were +origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices +working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer +buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass +storage devices to fail more frequently. + +USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically, +the TD fragment rules could have caused an occasional disk glitch. +Now the devices *will* fail, instead of theoretically failing. +>From a user perspective, this looks like a regression; the USB device obviously +fails on 3.14-rc1, and may sometimes silently fail on prior kernels. + +The proper soluition is to implement the TD fragment rules required, but for now +this patch needs to be reverted to get USB 3.0 mass storage devices working at the +level they used to. + +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci.c | 14 +++----------- + 1 file changed, 3 insertions(+), 11 deletions(-) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -4719,6 +4719,9 @@ int xhci_gen_setup(struct usb_hcd *hcd, + /* Accept arbitrarily long scatter-gather lists */ + hcd->self.sg_tablesize = ~0; + ++ /* support to build packet from discontinuous buffers */ ++ hcd->self.no_sg_constraint = 1; ++ + /* XHCI controllers don't stop the ep queue on short packets :| */ + hcd->self.no_stop_on_short = 1; + +@@ -4743,14 +4746,6 @@ int xhci_gen_setup(struct usb_hcd *hcd, + /* xHCI private pointer was set in xhci_pci_probe for the second + * registered roothub. + */ +- xhci = hcd_to_xhci(hcd); +- /* +- * Support arbitrarily aligned sg-list entries on hosts without +- * TD fragment rules (which are currently unsupported). +- */ +- if (xhci->hci_version < 0x100) +- hcd->self.no_sg_constraint = 1; +- + return 0; + } + +@@ -4777,9 +4772,6 @@ int xhci_gen_setup(struct usb_hcd *hcd, + if (xhci->hci_version > 0x96) + xhci->quirks |= XHCI_SPURIOUS_SUCCESS; + +- if (xhci->hci_version < 0x100) +- hcd->self.no_sg_constraint = 1; +- + /* Make sure the HC is halted. */ + retval = xhci_halt(xhci); + if (retval) diff --git a/queue-3.13/series b/queue-3.13/series index f94ae252125..851c5794efb 100644 --- a/queue-3.13/series +++ b/queue-3.13/series @@ -54,3 +54,20 @@ alsa-hda-fix-loud-click-noise-with-ideapad-410y.patch pinctrl-sunxi-use-chained_irq_-enter-exit-for-gic-compatibility.patch powerpc-tm-fix-crash-when-forking-inside-a-transaction.patch powerpc-align-p_dyn-p_rela-and-p_st-symbols.patch +drm-armada-fix-use-of-kfifo_put.patch +arm-fix-nommu-kallsyms-symbol-filtering.patch +arm-7991-1-sa1100-fix-compile-problem-on-collie.patch +regulator-core-replace-direct-ops-enable-usage.patch +x86-ignore-nmis-that-come-in-during-early-boot.patch +x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch +x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch +x86_pkg_temp_thermal-do-not-expose-as-a-hwmon-device.patch +revert-usbnet-ax88179_178a-enable-tso-if-usb-host-supports-sg-dma.patch +usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch +usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch +revert-xhci-1.0-limit-arbitrarily-aligned-scatter-gather.patch +genirq-remove-racy-waitqueue_active-check.patch +cpuset-fix-a-locking-issue-in-cpuset_migrate_mm.patch +cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch +acpi-resources-ignore-invalid-acpi-device-resources.patch +acpi-ec-clear-stale-ec-events-on-samsung-systems.patch diff --git a/queue-3.13/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch b/queue-3.13/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch new file mode 100644 index 00000000000..4299bd7a922 --- /dev/null +++ b/queue-3.13/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch @@ -0,0 +1,39 @@ +From e0429362ab15c46ea4d64c3f8c9e0933e48a143a Mon Sep 17 00:00:00 2001 +From: Julius Werner +Date: Tue, 4 Mar 2014 10:52:39 -0800 +Subject: usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e + +From: Julius Werner + +commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream. + +We've encountered a rare issue when enumerating two Logitech webcams +after a reboot that doesn't power cycle the USB ports. They are spewing +random data (possibly some leftover UVC buffers) on the second +(full-sized) Get Configuration request of the enumeration phase. Since +the data is random this can potentially cause all kinds of odd behavior, +and since it occasionally happens multiple times (after the kernel +issues another reset due to the garbled configuration descriptor), it is +not always recoverable. Set the USB_DELAY_INIT quirk that seems to work +around the issue. + +Signed-off-by: Julius Werner +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/quirks.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -47,6 +47,10 @@ static const struct usb_device_id usb_qu + /* Microsoft LifeCam-VX700 v2.0 */ + { USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME }, + ++ /* Logitech HD Pro Webcams C920 and C930e */ ++ { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT }, ++ { USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT }, ++ + /* Logitech Quickcam Fusion */ + { USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME }, + diff --git a/queue-3.13/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch b/queue-3.13/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch new file mode 100644 index 00000000000..0138f497928 --- /dev/null +++ b/queue-3.13/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch @@ -0,0 +1,39 @@ +From d86db25e53fa69e3e97f3b55dd82a70689787c5d Mon Sep 17 00:00:00 2001 +From: Julius Werner +Date: Tue, 4 Mar 2014 11:27:38 -0800 +Subject: usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests + +From: Julius Werner + +commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream. + +The DELAY_INIT quirk only reduces the frequency of enumeration failures +with the Logitech HD Pro C920 and C930e webcams, but does not quite +eliminate them. We have found that adding a delay of 100ms between the +first and second Get Configuration request makes the device enumerate +perfectly reliable even after several weeks of extensive testing. The +reasons for that are anyone's guess, but since the DELAY_INIT quirk +already delays enumeration by a whole second, wating for another 10th of +that isn't really a big deal for the one other device that uses it, and +it will resolve the problems with these webcams. + +Signed-off-by: Julius Werner +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/config.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/usb/core/config.c ++++ b/drivers/usb/core/config.c +@@ -718,6 +718,10 @@ int usb_get_configuration(struct usb_dev + result = -ENOMEM; + goto err; + } ++ ++ if (dev->quirks & USB_QUIRK_DELAY_INIT) ++ msleep(100); ++ + result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, + bigbuffer, length); + if (result < 0) { diff --git a/queue-3.13/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch b/queue-3.13/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch new file mode 100644 index 00000000000..bf578a0fc7c --- /dev/null +++ b/queue-3.13/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch @@ -0,0 +1,41 @@ +From 847d7970defb45540735b3fb4e88471c27cacd85 Mon Sep 17 00:00:00 2001 +From: Daniel J Blueman +Date: Thu, 13 Mar 2014 19:43:01 +0800 +Subject: x86/amd/numa: Fix northbridge quirk to assign correct NUMA node + +From: Daniel J Blueman + +commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream. + +For systems with multiple servers and routed fabric, all +northbridges get assigned to the first server. Fix this by also +using the node reported from the PCI bus. For single-fabric +systems, the northbriges are on PCI bus 0 by definition, which +are on NUMA node 0 by definition, so this is invarient on most +systems. + +Tested on fam10h and fam15h single and multi-fabric systems and +candidate for stable. + +Signed-off-by: Daniel J Blueman +Acked-by: Steffen Persvold +Acked-by: Borislav Petkov +Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/quirks.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/quirks.c ++++ b/arch/x86/kernel/quirks.c +@@ -529,7 +529,7 @@ static void quirk_amd_nb_node(struct pci + return; + + pci_read_config_dword(nb_ht, 0x60, &val); +- node = val & 7; ++ node = pcibus_to_node(dev->bus) | (val & 7); + /* + * Some hardware may return an invalid node ID, + * so check it first: diff --git a/queue-3.13/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch b/queue-3.13/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch new file mode 100644 index 00000000000..40afc008c0b --- /dev/null +++ b/queue-3.13/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch @@ -0,0 +1,51 @@ +From b01d4e68933ec23e43b1046fa35d593cefcf37d1 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Fri, 7 Mar 2014 18:58:40 -0800 +Subject: x86: fix compile error due to X86_TRAP_NMI use in asm files + +From: Linus Torvalds + +commit b01d4e68933ec23e43b1046fa35d593cefcf37d1 upstream. + +It's an enum, not a #define, you can't use it in asm files. + +Introduced in commit 5fa10196bdb5 ("x86: Ignore NMIs that come in during +early boot"), and sadly I didn't compile-test things like I should have +before pushing out. + +My weak excuse is that the x86 tree generally doesn't introduce stupid +things like this (and the ARM pull afterwards doesn't cause me to do a +compile-test either, since I don't cross-compile). + +Cc: Don Zickus +Cc: H. Peter Anvin +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/head_32.S | 2 +- + arch/x86/kernel/head_64.S | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/head_32.S ++++ b/arch/x86/kernel/head_32.S +@@ -545,7 +545,7 @@ ENDPROC(early_idt_handlers) + ENTRY(early_idt_handler) + cld + +- cmpl $X86_TRAP_NMI,(%esp) ++ cmpl $2,(%esp) # X86_TRAP_NMI + je is_nmi # Ignore NMI + + cmpl $2,%ss:early_recursion_flag +--- a/arch/x86/kernel/head_64.S ++++ b/arch/x86/kernel/head_64.S +@@ -343,7 +343,7 @@ early_idt_handlers: + ENTRY(early_idt_handler) + cld + +- cmpl $X86_TRAP_NMI,(%rsp) ++ cmpl $2,(%rsp) # X86_TRAP_NMI + je is_nmi # Ignore NMI + + cmpl $2,early_recursion_flag(%rip) diff --git a/queue-3.13/x86-ignore-nmis-that-come-in-during-early-boot.patch b/queue-3.13/x86-ignore-nmis-that-come-in-during-early-boot.patch new file mode 100644 index 00000000000..808e7d3939a --- /dev/null +++ b/queue-3.13/x86-ignore-nmis-that-come-in-during-early-boot.patch @@ -0,0 +1,83 @@ +From 5fa10196bdb5f190f595ebd048490ee52dddea0f Mon Sep 17 00:00:00 2001 +From: "H. Peter Anvin" +Date: Fri, 7 Mar 2014 15:05:20 -0800 +Subject: x86: Ignore NMIs that come in during early boot + +From: "H. Peter Anvin" + +commit 5fa10196bdb5f190f595ebd048490ee52dddea0f upstream. + +Don Zickus reports: + +A customer generated an external NMI using their iLO to test kdump +worked. Unfortunately, the machine hung. Disabling the nmi_watchdog +made things work. + +I speculated the external NMI fired, caused the machine to panic (as +expected) and the perf NMI from the watchdog came in and was latched. +My guess was this somehow caused the hang. + + ---- + +It appears that the latched NMI stays latched until the early page +table generation on 64 bits, which causes exceptions to happen which +end in IRET, which re-enable NMI. Therefore, ignore NMIs that come in +during early execution, until we have proper exception handling. + +Reported-and-tested-by: Don Zickus +Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/head_32.S | 7 ++++++- + arch/x86/kernel/head_64.S | 6 +++++- + 2 files changed, 11 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/head_32.S ++++ b/arch/x86/kernel/head_32.S +@@ -544,6 +544,10 @@ ENDPROC(early_idt_handlers) + /* This is global to keep gas from relaxing the jumps */ + ENTRY(early_idt_handler) + cld ++ ++ cmpl $X86_TRAP_NMI,(%esp) ++ je is_nmi # Ignore NMI ++ + cmpl $2,%ss:early_recursion_flag + je hlt_loop + incl %ss:early_recursion_flag +@@ -594,8 +598,9 @@ ex_entry: + pop %edx + pop %ecx + pop %eax +- addl $8,%esp /* drop vector number and error code */ + decl %ss:early_recursion_flag ++is_nmi: ++ addl $8,%esp /* drop vector number and error code */ + iret + ENDPROC(early_idt_handler) + +--- a/arch/x86/kernel/head_64.S ++++ b/arch/x86/kernel/head_64.S +@@ -343,6 +343,9 @@ early_idt_handlers: + ENTRY(early_idt_handler) + cld + ++ cmpl $X86_TRAP_NMI,(%rsp) ++ je is_nmi # Ignore NMI ++ + cmpl $2,early_recursion_flag(%rip) + jz 1f + incl early_recursion_flag(%rip) +@@ -405,8 +408,9 @@ ENTRY(early_idt_handler) + popq %rdx + popq %rcx + popq %rax +- addq $16,%rsp # drop vector number and error code + decl early_recursion_flag(%rip) ++is_nmi: ++ addq $16,%rsp # drop vector number and error code + INTERRUPT_RETURN + ENDPROC(early_idt_handler) + diff --git a/queue-3.13/x86_pkg_temp_thermal-do-not-expose-as-a-hwmon-device.patch b/queue-3.13/x86_pkg_temp_thermal-do-not-expose-as-a-hwmon-device.patch new file mode 100644 index 00000000000..9dee312aaf8 --- /dev/null +++ b/queue-3.13/x86_pkg_temp_thermal-do-not-expose-as-a-hwmon-device.patch @@ -0,0 +1,46 @@ +From 79786880a47a8c5b4c8146c03432b3387a07a169 Mon Sep 17 00:00:00 2001 +From: Jean Delvare +Date: Sun, 2 Mar 2014 15:33:35 +0100 +Subject: x86_pkg_temp_thermal: Do not expose as a hwmon device + +From: Jean Delvare + +commit 79786880a47a8c5b4c8146c03432b3387a07a169 upstream. + +The temperature value reported by x86_pkg_temp_thermal is already +reported by the coretemp driver. So, do not expose this thermal zone +as a hwmon device, because it would be redundant. + +Signed-off-by: Jean Delvare +Cc: Zhang Rui +Cc: Eduardo Valentin +Acked-by: Guenter Roeck +Signed-off-by: Zhang Rui +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/thermal/x86_pkg_temp_thermal.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/thermal/x86_pkg_temp_thermal.c ++++ b/drivers/thermal/x86_pkg_temp_thermal.c +@@ -68,6 +68,10 @@ struct phy_dev_entry { + struct thermal_zone_device *tzone; + }; + ++static const struct thermal_zone_params pkg_temp_tz_params = { ++ .no_hwmon = true, ++}; ++ + /* List maintaining number of package instances */ + static LIST_HEAD(phy_dev_list); + static DEFINE_MUTEX(phy_dev_list_mutex); +@@ -446,7 +450,7 @@ static int pkg_temp_thermal_device_add(u + thres_count, + (thres_count == MAX_NUMBER_OF_TRIPS) ? + 0x03 : 0x01, +- phy_dev_entry, &tzone_ops, NULL, 0, 0); ++ phy_dev_entry, &tzone_ops, &pkg_temp_tz_params, 0, 0); + if (IS_ERR(phy_dev_entry->tzone)) { + err = PTR_ERR(phy_dev_entry->tzone); + goto err_ret_free;