--- /dev/null
+From ad332c8a45330d170bb38b95209de449b31cd1b4 Mon Sep 17 00:00:00 2001
+From: Kieran Clancy <clancy.kieran@gmail.com>
+Date: Sat, 1 Mar 2014 00:42:28 +1030
+Subject: ACPI / EC: Clear stale EC events on Samsung systems
+
+From: Kieran Clancy <clancy.kieran@gmail.com>
+
+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 <juanmanuel.cabo@gmail.com>
+Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com>
+Reviewed-by: Lan Tianyu <tianyu.lan@intel.com>
+Reviewed-by: Dennis Jansen <dennis.jansen@web.de>
+Tested-by: Kieran Clancy <clancy.kieran@gmail.com>
+Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com>
+Tested-by: Dennis Jansen <dennis.jansen@web.de>
+Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com>
+Tested-by: San Zamoyski <san@plusnet.pl>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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},
+ {},
+ };
+
--- /dev/null
+From b355cee88e3b1a193f0e9a81db810f6f83ad728b Mon Sep 17 00:00:00 2001
+From: Zhang Rui <rui.zhang@intel.com>
+Date: Thu, 27 Feb 2014 11:37:15 +0800
+Subject: ACPI / resources: ignore invalid ACPI device resources
+
+From: Zhang Rui <rui.zhang@intel.com>
+
+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 <rui.zhang@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 052450fdc55894a39fbae93d9bbe43947956f663 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Tue, 25 Feb 2014 22:41:41 +0100
+Subject: ARM: 7991/1: sa1100: fix compile problem on Collie
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+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 <mach/collie.h>
+implicitly requiring <mach/hardware.h> through <linux/gpio.h>
+via <mach/gpio.h> prior to commit
+40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".
+
+Fix this up by including the required header into
+<mach/collie.h>.
+
+Cc: Andrea Adami <andrea.adami@gmail.com>
+Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 006fa2599bf0daf107cbb7a8a99fcfb9a998a169 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Wed, 26 Feb 2014 19:40:46 +0000
+Subject: ARM: fix noMMU kallsyms symbol filtering
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+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 <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.
+ */
--- /dev/null
+From 4729583006772b9530404bc1bb7c3aa4a10ffd4d Mon Sep 17 00:00:00 2001
+From: Li Zefan <lizefan@huawei.com>
+Date: Thu, 27 Feb 2014 18:19:03 +0800
+Subject: cpuset: fix a locking issue in cpuset_migrate_mm()
+
+From: Li Zefan <lizefan@huawei.com>
+
+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!
+ ...
+ [<ffffffff81582174>] dump_stack+0x72/0x86
+ [<ffffffff810b8f01>] lockdep_rcu_suspicious+0x101/0x140
+ [<ffffffff81105ba1>] 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 <lizefan@huawei.com>
+Sigend-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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();
+ }
+
+ /*
--- /dev/null
+From 99afb0fd5f05aac467ffa85c36778fec4396209b Mon Sep 17 00:00:00 2001
+From: Li Zefan <lizefan@huawei.com>
+Date: Thu, 27 Feb 2014 18:19:36 +0800
+Subject: cpuset: fix a race condition in __cpuset_node_allowed_softwall()
+
+From: Li Zefan <lizefan@huawei.com>
+
+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 <lizefan@huawei.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From d13c46c67e546bb1dc1c4dc7c43e388d0119276b Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Mon, 3 Mar 2014 14:49:51 +0000
+Subject: DRM: armada: fix use of kfifo_put()
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+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 <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From c685689fd24d310343ac33942e9a54a974ae9c43 Mon Sep 17 00:00:00 2001
+From: Chuansheng Liu <chuansheng.liu@intel.com>
+Date: Mon, 24 Feb 2014 11:29:50 +0800
+Subject: genirq: Remove racy waitqueue_active check
+
+From: Chuansheng Liu <chuansheng.liu@intel.com>
+
+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 <chuansheng.liu@intel.com>
+Cc: Xiaoming Wang <xiaoming.wang@intel.com>
+Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b Mon Sep 17 00:00:00 2001
+From: Markus Pargmann <mpa@pengutronix.de>
+Date: Thu, 20 Feb 2014 17:36:03 +0100
+Subject: regulator: core: Replace direct ops->enable usage
+
+From: Markus Pargmann <mpa@pengutronix.de>
+
+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 <mpa@pengutronix.de>
+Signed-off-by: Mark Brown <broonie@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ 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 {
--- /dev/null
+From 469d417b68958a064c09e7875646c97c6e783dfc Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+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 <mathias.nyman@linux.intel.com>
+
+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 <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From e2ed511400d41e0d136089d5a55ceab57c6a2426 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 7 Mar 2014 17:06:57 +0200
+Subject: Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+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 <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
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
--- /dev/null
+From e0429362ab15c46ea4d64c3f8c9e0933e48a143a Mon Sep 17 00:00:00 2001
+From: Julius Werner <jwerner@chromium.org>
+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 <jwerner@chromium.org>
+
+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 <jwerner@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 },
+
--- /dev/null
+From d86db25e53fa69e3e97f3b55dd82a70689787c5d Mon Sep 17 00:00:00 2001
+From: Julius Werner <jwerner@chromium.org>
+Date: Tue, 4 Mar 2014 11:27:38 -0800
+Subject: usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
+
+From: Julius Werner <jwerner@chromium.org>
+
+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 <jwerner@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 847d7970defb45540735b3fb4e88471c27cacd85 Mon Sep 17 00:00:00 2001
+From: Daniel J Blueman <daniel@numascale.com>
+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 <daniel@numascale.com>
+
+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 <daniel@numascale.com>
+Acked-by: Steffen Persvold <sp@numascale.com>
+Acked-by: Borislav Petkov <bp@suse.de>
+Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From b01d4e68933ec23e43b1046fa35d593cefcf37d1 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+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 <torvalds@linux-foundation.org>
+
+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 <dzickus@redhat.com>
+Cc: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 5fa10196bdb5f190f595ebd048490ee52dddea0f Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+Date: Fri, 7 Mar 2014 15:05:20 -0800
+Subject: x86: Ignore NMIs that come in during early boot
+
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+
+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 <dzickus@redhat.com>
+Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
+
--- /dev/null
+From 79786880a47a8c5b4c8146c03432b3387a07a169 Mon Sep 17 00:00:00 2001
+From: Jean Delvare <jdelvare@suse.de>
+Date: Sun, 2 Mar 2014 15:33:35 +0100
+Subject: x86_pkg_temp_thermal: Do not expose as a hwmon device
+
+From: Jean Delvare <jdelvare@suse.de>
+
+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 <jdelvare@suse.de>
+Cc: Zhang Rui <rui.zhang@intel.com>
+Cc: Eduardo Valentin <eduardo.valentin@ti.com>
+Acked-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
