--- /dev/null
+From 3eba563e280101209bad27d40bfc83ddf1489234 Mon Sep 17 00:00:00 2001
+From: Kieran Clancy <clancy.kieran@gmail.com>
+Date: Wed, 30 Apr 2014 00:21:20 +0930
+Subject: ACPI / EC: Process rather than discard events in acpi_ec_clear
+
+From: Kieran Clancy <clancy.kieran@gmail.com>
+
+commit 3eba563e280101209bad27d40bfc83ddf1489234 upstream.
+
+Address a regression caused by commit ad332c8a4533:
+(ACPI / EC: Clear stale EC events on Samsung systems)
+
+After the earlier patch, there was found to be a race condition on some
+earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was
+sometimes discarding a new EC event before its GPE was triggered by the
+system. In the case of these systems, this meant that the "lid open"
+event was not registered on resume if that was the cause of the wake,
+leading to problems when attempting to close the lid to suspend again.
+
+After testing on a number of Samsung systems, both those affected by the
+previous EC bug and those affected by the race condition, it seemed that
+the best course of action was to process rather than discard the events.
+On Samsung systems which accumulate stale EC events, there does not seem
+to be any adverse side-effects of running the associated _Q methods.
+
+This patch adds an argument to the static function acpi_ec_sync_query so
+that it may be used within the acpi_ec_clear loop in place of
+acpi_ec_query_unlocked which was used previously.
+
+With thanks to Stefan Biereigel for reporting the issue, and for all the
+people who helped test the new patch on affected systems.
+
+Fixes: ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems)
+References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de
+References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173
+Reported-by: Stefan Biereigel <stefan@biereigel.de>
+Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com>
+Tested-by: Stefan Biereigel <stefan@biereigel.de>
+Tested-by: Dennis Jansen <dennis.jansen@web.de>
+Tested-by: Nicolas Porcel <nicolasporcel06@gmail.com>
+Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com>
+Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com>
+Tested-by: Giannis Koutsou <giannis.koutsou@gmail.com>
+Tested-by: Kieran Clancy <clancy.kieran@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/ec.c | 21 ++++++++++++---------
+ 1 file changed, 12 insertions(+), 9 deletions(-)
+
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -206,13 +206,13 @@ unlock:
+ spin_unlock_irqrestore(&ec->lock, flags);
+ }
+
+-static int acpi_ec_sync_query(struct acpi_ec *ec);
++static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data);
+
+ static int ec_check_sci_sync(struct acpi_ec *ec, u8 state)
+ {
+ if (state & ACPI_EC_FLAG_SCI) {
+ if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
+- return acpi_ec_sync_query(ec);
++ return acpi_ec_sync_query(ec, NULL);
+ }
+ return 0;
+ }
+@@ -443,10 +443,8 @@ 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.
++ * Process _Q events that might have accumulated in the EC.
+ * Run with locked ec mutex.
+ */
+ static void acpi_ec_clear(struct acpi_ec *ec)
+@@ -455,7 +453,7 @@ static void acpi_ec_clear(struct acpi_ec
+ u8 value = 0;
+
+ for (i = 0; i < ACPI_EC_CLEAR_MAX; i++) {
+- status = acpi_ec_query_unlocked(ec, &value);
++ status = acpi_ec_sync_query(ec, &value);
+ if (status || !value)
+ break;
+ }
+@@ -582,13 +580,18 @@ static void acpi_ec_run(void *cxt)
+ kfree(handler);
+ }
+
+-static int acpi_ec_sync_query(struct acpi_ec *ec)
++static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data)
+ {
+ u8 value = 0;
+ int status;
+ struct acpi_ec_query_handler *handler, *copy;
+- if ((status = acpi_ec_query_unlocked(ec, &value)))
++
++ status = acpi_ec_query_unlocked(ec, &value);
++ if (data)
++ *data = value;
++ if (status)
+ return status;
++
+ list_for_each_entry(handler, &ec->list, node) {
+ if (value == handler->query_bit) {
+ /* have custom handler for this bit */
+@@ -612,7 +615,7 @@ static void acpi_ec_gpe_query(void *ec_c
+ if (!ec)
+ return;
+ mutex_lock(&ec->mutex);
+- acpi_ec_sync_query(ec);
++ acpi_ec_sync_query(ec, NULL);
+ mutex_unlock(&ec->mutex);
+ }
+
--- /dev/null
+From 754320d6e166d3a12cb4810a452bde00afbd4e9a Mon Sep 17 00:00:00 2001
+From: Leon Yu <chianglungyu@gmail.com>
+Date: Thu, 1 May 2014 03:31:28 +0000
+Subject: aio: fix potential leak in aio_run_iocb().
+
+From: Leon Yu <chianglungyu@gmail.com>
+
+commit 754320d6e166d3a12cb4810a452bde00afbd4e9a upstream.
+
+iovec should be reclaimed whenever caller of rw_copy_check_uvector() returns,
+but it doesn't hold when failure happens right after aio_setup_vectored_rw().
+
+Fix that in a such way to avoid hairy goto.
+
+Signed-off-by: Leon Yu <chianglungyu@gmail.com>
+Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/aio.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/fs/aio.c
++++ b/fs/aio.c
+@@ -1299,10 +1299,8 @@ rw_common:
+ &iovec, compat)
+ : aio_setup_single_vector(req, rw, buf, &nr_segs,
+ iovec);
+- if (ret)
+- return ret;
+-
+- ret = rw_verify_area(rw, file, &req->ki_pos, req->ki_nbytes);
++ if (!ret)
++ ret = rw_verify_area(rw, file, &req->ki_pos, req->ki_nbytes);
+ if (ret < 0) {
+ if (iovec != &inline_vec)
+ kfree(iovec);
--- /dev/null
+From 131cd131a9ff63d4b84f3fe15073a2984ac30066 Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Thu, 1 May 2014 16:14:24 -0400
+Subject: dm cache: fix writethrough mode quiescing in cache_map
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit 131cd131a9ff63d4b84f3fe15073a2984ac30066 upstream.
+
+Commit 2ee57d58735 ("dm cache: add passthrough mode") inadvertently
+removed the deferred set reference that was taken in cache_map()'s
+writethrough mode support. Restore taking this reference.
+
+This issue was found with code inspection.
+
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Acked-by: Joe Thornber <ejt@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-cache-target.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/dm-cache-target.c
++++ b/drivers/md/dm-cache-target.c
+@@ -2506,6 +2506,7 @@ static int cache_map(struct dm_target *t
+
+ } else {
+ inc_hit_counter(cache, bio);
++ pb->all_io_entry = dm_deferred_entry_inc(cache->all_io_ds);
+
+ if (bio_data_dir(bio) == WRITE && writethrough_mode(&cache->features) &&
+ !is_dirty(cache, lookup_result.cblock))
--- /dev/null
+From 3a7745215e7f73a5c7d9bcdc50661a55b39052a3 Mon Sep 17 00:00:00 2001
+From: Milan Broz <gmazyland@gmail.com>
+Date: Mon, 14 Apr 2014 22:02:30 +0200
+Subject: dm verity: fix biovecs hash calculation regression
+
+From: Milan Broz <gmazyland@gmail.com>
+
+commit 3a7745215e7f73a5c7d9bcdc50661a55b39052a3 upstream.
+
+Commit 003b5c5719f159f4f4bf97511c4702a0638313dd ("block: Convert drivers
+to immutable biovecs") incorrectly converted biovec iteration in
+dm-verity to always calculate the hash from a full biovec, but the
+function only needs to calculate the hash from part of the biovec (up to
+the calculated "todo" value).
+
+Fix this issue by limiting hash input to only the requested data size.
+
+This problem was identified using the cryptsetup regression test for
+veritysetup (verity-compat-test).
+
+Signed-off-by: Milan Broz <gmazyland@gmail.com>
+Acked-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-verity.c | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/drivers/md/dm-verity.c
++++ b/drivers/md/dm-verity.c
+@@ -330,15 +330,17 @@ test_block_hash:
+ return r;
+ }
+ }
+-
+ todo = 1 << v->data_dev_block_bits;
+- while (io->iter.bi_size) {
++ do {
+ u8 *page;
++ unsigned len;
+ struct bio_vec bv = bio_iter_iovec(bio, io->iter);
+
+ page = kmap_atomic(bv.bv_page);
+- r = crypto_shash_update(desc, page + bv.bv_offset,
+- bv.bv_len);
++ len = bv.bv_len;
++ if (likely(len >= todo))
++ len = todo;
++ r = crypto_shash_update(desc, page + bv.bv_offset, len);
+ kunmap_atomic(page);
+
+ if (r < 0) {
+@@ -346,8 +348,9 @@ test_block_hash:
+ return r;
+ }
+
+- bio_advance_iter(bio, &io->iter, bv.bv_len);
+- }
++ bio_advance_iter(bio, &io->iter, len);
++ todo -= len;
++ } while (todo);
+
+ if (!v->version) {
+ r = crypto_shash_update(desc, v->salt, v->salt_size);
--- /dev/null
+From 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 Mon Sep 17 00:00:00 2001
+From: Grant Likely <grant.likely@linaro.org>
+Date: Tue, 29 Apr 2014 12:05:22 +0100
+Subject: drivercore: deferral race condition fix
+
+From: Grant Likely <grant.likely@linaro.org>
+
+commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream.
+
+When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
+when all modules loaded but some driver still stuck in the deferred list
+and there is a need for external event to kick the deferred queue to probe
+these drivers.
+
+The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
+audio support built as modules and using nfsroot for root filesystem.
+
+The following log fragment shows such sequence when all audio modules
+were loaded but the sound card is not present since the machine driver has
+failed to probe due to missing dependency during it's probe.
+The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
+machine driver:
+
+...
+[ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
+[ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
+[ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
+[ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
+[ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
+[ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
+[ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
+[ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
+[ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
+[ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
+[ 13.346755] davinci_mcasp_driver_init: LEAVE
+[ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral
+[ 13.592527] platform sound.3: really_probe: probe_count = 0
+
+In the log the machine driver enters it's probe at 12.719969 (this point it
+has been removed from the deferred lists). McASP driver already executing
+it's probing (since 12.615118).
+The machine driver tries to construct the sound card (12.950839) but did
+not found one of the components so it fails. After this McASP driver
+registers all the ASoC components (the machine driver still in it's probe
+function after it failed to construct the card) and the deferred work is
+prepared at 13.099026 (note that this time the machine driver is not in the
+lists so it is not going to be handled when the work is executing).
+Lastly the machine driver exit from it's probe and the core places it to
+the deferred list but there will be no other driver going to load and the
+deferred queue is not going to be kicked again - till we have external event
+like connecting USB stick, etc.
+
+The proposed solution is to try the deferred queue once more when the last
+driver is asking for deferring and we had drivers loaded while this last
+driver was probing.
+
+This way we can avoid drivers stuck in the deferred queue.
+
+Signed-off-by: Grant Likely <grant.likely@linaro.org>
+Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/dd.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/drivers/base/dd.c
++++ b/drivers/base/dd.c
+@@ -52,6 +52,7 @@ static DEFINE_MUTEX(deferred_probe_mutex
+ static LIST_HEAD(deferred_probe_pending_list);
+ static LIST_HEAD(deferred_probe_active_list);
+ static struct workqueue_struct *deferred_wq;
++static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
+
+ /**
+ * deferred_probe_work_func() - Retry probing devices in the active list.
+@@ -135,6 +136,17 @@ static bool driver_deferred_probe_enable
+ * This functions moves all devices from the pending list to the active
+ * list and schedules the deferred probe workqueue to process them. It
+ * should be called anytime a driver is successfully bound to a device.
++ *
++ * Note, there is a race condition in multi-threaded probe. In the case where
++ * more than one device is probing at the same time, it is possible for one
++ * probe to complete successfully while another is about to defer. If the second
++ * depends on the first, then it will get put on the pending list after the
++ * trigger event has already occured and will be stuck there.
++ *
++ * The atomic 'deferred_trigger_count' is used to determine if a successful
++ * trigger has occurred in the midst of probing a driver. If the trigger count
++ * changes in the midst of a probe, then deferred processing should be triggered
++ * again.
+ */
+ static void driver_deferred_probe_trigger(void)
+ {
+@@ -147,6 +159,7 @@ static void driver_deferred_probe_trigge
+ * into the active list so they can be retried by the workqueue
+ */
+ mutex_lock(&deferred_probe_mutex);
++ atomic_inc(&deferred_trigger_count);
+ list_splice_tail_init(&deferred_probe_pending_list,
+ &deferred_probe_active_list);
+ mutex_unlock(&deferred_probe_mutex);
+@@ -265,6 +278,7 @@ static DECLARE_WAIT_QUEUE_HEAD(probe_wai
+ static int really_probe(struct device *dev, struct device_driver *drv)
+ {
+ int ret = 0;
++ int local_trigger_count = atomic_read(&deferred_trigger_count);
+
+ atomic_inc(&probe_count);
+ pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
+@@ -310,6 +324,9 @@ probe_failed:
+ /* Driver requested deferred probing */
+ dev_info(dev, "Driver %s requests probe deferral\n", drv->name);
+ driver_deferred_probe_add(dev);
++ /* Did a trigger occur while probing? Need to re-trigger if yes */
++ if (local_trigger_count != atomic_read(&deferred_trigger_count))
++ driver_deferred_probe_trigger();
+ } else if (ret != -ENODEV && ret != -ENXIO) {
+ /* driver matched but the probe failed */
+ printk(KERN_WARNING
--- /dev/null
+From 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 Mon Sep 17 00:00:00 2001
+From: Stuart Hayes <stuart.w.hayes@gmail.com>
+Date: Tue, 29 Apr 2014 17:55:02 -0500
+Subject: hrtimer: Prevent all reprogramming if hang detected
+
+From: Stuart Hayes <stuart.w.hayes@gmail.com>
+
+commit 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 upstream.
+
+If the last hrtimer interrupt detected a hang it sets hang_detected=1
+and programs the clock event device with a delay to let the system
+make progress.
+
+If hang_detected == 1, we prevent reprogramming of the clock event
+device in hrtimer_reprogram() but not in hrtimer_force_reprogram().
+
+This can lead to the following situation:
+
+hrtimer_interrupt()
+ hang_detected = 1;
+ program ce device to Xms from now (hang delay)
+
+We have two timers pending:
+ T1 expires 50ms from now
+ T2 expires 5s from now
+
+Now T1 gets canceled, which causes hrtimer_force_reprogram() to be
+invoked, which in turn programs the clock event device to T2 (5
+seconds from now).
+
+Any hrtimer_start after that will not reprogram the hardware due to
+hang_detected still being set. So we effectivly block all timers until
+the T2 event fires and cleans up the hang situation.
+
+Add a check for hang_detected to hrtimer_force_reprogram() which
+prevents the reprogramming of the hang delay in the hardware
+timer. The subsequent hrtimer_interrupt will resolve all outstanding
+issues.
+
+[ tglx: Rewrote subject and changelog and fixed up the comment in
+ hrtimer_force_reprogram() ]
+
+Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
+Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/hrtimer.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/kernel/hrtimer.c
++++ b/kernel/hrtimer.c
+@@ -582,6 +582,23 @@ hrtimer_force_reprogram(struct hrtimer_c
+
+ cpu_base->expires_next.tv64 = expires_next.tv64;
+
++ /*
++ * If a hang was detected in the last timer interrupt then we
++ * leave the hang delay active in the hardware. We want the
++ * system to make progress. That also prevents the following
++ * scenario:
++ * T1 expires 50ms from now
++ * T2 expires 5s from now
++ *
++ * T1 is removed, so this code is called and would reprogram
++ * the hardware to 5s from now. Any hrtimer_start after that
++ * will not reprogram the hardware due to hang_detected being
++ * set. So we'd effectivly block all timers until the T2 event
++ * fires.
++ */
++ if (cpu_base->hang_detected)
++ return;
++
+ if (cpu_base->expires_next.tv64 != KTIME_MAX)
+ tick_program_event(cpu_base->expires_next, 1);
+ }
--- /dev/null
+From 012a45e3f4af68e86d85cce060c6c2fed56498b2 Mon Sep 17 00:00:00 2001
+From: Leon Ma <xindong.ma@intel.com>
+Date: Wed, 30 Apr 2014 16:43:10 +0800
+Subject: hrtimer: Prevent remote enqueue of leftmost timers
+
+From: Leon Ma <xindong.ma@intel.com>
+
+commit 012a45e3f4af68e86d85cce060c6c2fed56498b2 upstream.
+
+If a cpu is idle and starts an hrtimer which is not pinned on that
+same cpu, the nohz code might target the timer to a different cpu.
+
+In the case that we switch the cpu base of the timer we already have a
+sanity check in place, which determines whether the timer is earlier
+than the current leftmost timer on the target cpu. In that case we
+enqueue the timer on the current cpu because we cannot reprogram the
+clock event device on the target.
+
+If the timers base is already the target CPU we do not have this
+sanity check in place so we enqueue the timer as the leftmost timer in
+the target cpus rb tree, but we cannot reprogram the clock event
+device on the target cpu. So the timer expires late and subsequently
+prevents the reprogramming of the target cpu clock event device until
+the previously programmed event fires or a timer with an earlier
+expiry time gets enqueued on the target cpu itself.
+
+Add the same target check as we have for the switch base case and
+start the timer on the current cpu if it would become the leftmost
+timer on the target.
+
+[ tglx: Rewrote subject and changelog ]
+
+Signed-off-by: Leon Ma <xindong.ma@intel.com>
+Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/hrtimer.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/kernel/hrtimer.c
++++ b/kernel/hrtimer.c
+@@ -247,6 +247,11 @@ again:
+ goto again;
+ }
+ timer->base = new_base;
++ } else {
++ if (cpu != this_cpu && hrtimer_check_target(timer, new_base)) {
++ cpu = this_cpu;
++ goto again;
++ }
+ }
+ return new_base;
+ }
--- /dev/null
+From 84ea7fe37908254c3bd90910921f6e1045c1747a Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Mon, 12 May 2014 13:42:29 +0530
+Subject: hrtimer: Set expiry time before switch_hrtimer_base()
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.
+
+switch_hrtimer_base() calls hrtimer_check_target() which ensures that
+we do not migrate a timer to a remote cpu if the timer expires before
+the current programmed expiry time on that remote cpu.
+
+But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
+new expiry time is set. So the sanity check in hrtimer_check_target()
+is operating on stale or even uninitialized data.
+
+Update expiry time before calling switch_hrtimer_base().
+
+[ tglx: Rewrote changelog once again ]
+
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Cc: linaro-kernel@lists.linaro.org
+Cc: linaro-networking@linaro.org
+Cc: fweisbec@gmail.com
+Cc: arvind.chauhan@arm.com
+Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.org
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/hrtimer.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/kernel/hrtimer.c
++++ b/kernel/hrtimer.c
+@@ -1003,11 +1003,8 @@ int __hrtimer_start_range_ns(struct hrti
+ /* Remove an active timer from the queue: */
+ ret = remove_hrtimer(timer, base);
+
+- /* Switch the timer base, if necessary: */
+- new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
+-
+ if (mode & HRTIMER_MODE_REL) {
+- tim = ktime_add_safe(tim, new_base->get_time());
++ tim = ktime_add_safe(tim, base->get_time());
+ /*
+ * CONFIG_TIME_LOW_RES is a temporary way for architectures
+ * to signal that they simply return xtime in
+@@ -1022,6 +1019,9 @@ int __hrtimer_start_range_ns(struct hrti
+
+ hrtimer_set_expires_range_ns(timer, tim, delta_ns);
+
++ /* Switch the timer base, if necessary: */
++ new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
++
+ timer_stats_hrtimer_set_start_info(timer);
+
+ leftmost = enqueue_hrtimer(timer, new_base);
--- /dev/null
+From 17c048fc4bd95efea208a1920f169547d8588f1f Mon Sep 17 00:00:00 2001
+From: Josef Gajdusek <atx@atx.name>
+Date: Sun, 11 May 2014 14:40:44 +0200
+Subject: hwmon: (emc1403) fix inverted store_hyst()
+
+From: Josef Gajdusek <atx@atx.name>
+
+commit 17c048fc4bd95efea208a1920f169547d8588f1f upstream.
+
+Attempts to set the hysteresis value to a temperature below the target
+limit fails with "write error: Numerical result out of range" due to
+an inverted comparison.
+
+Signed-off-by: Josef Gajdusek <atx@atx.name>
+Reviewed-by: Jean Delvare <jdelvare@suse.de>
+[Guenter Roeck: Updated headline and description]
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/emc1403.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hwmon/emc1403.c
++++ b/drivers/hwmon/emc1403.c
+@@ -163,7 +163,7 @@ static ssize_t store_hyst(struct device
+ if (retval < 0)
+ goto fail;
+
+- hyst = val - retval * 1000;
++ hyst = retval * 1000 - val;
+ hyst = DIV_ROUND_CLOSEST(hyst, 1000);
+ if (hyst < 0 || hyst > 255) {
+ retval = -ERANGE;
--- /dev/null
+From 8759f9046550f463098148bf577ccd32cdb895e3 Mon Sep 17 00:00:00 2001
+From: Jean Delvare <jdelvare@suse.de>
+Date: Mon, 12 May 2014 11:44:51 +0200
+Subject: hwmon: (emc1403) Fix resource leak on module unload
+
+From: Jean Delvare <jdelvare@suse.de>
+
+commit 8759f9046550f463098148bf577ccd32cdb895e3 upstream.
+
+Commit 454aee17f claims to convert driver emc1403 to use
+devm_hwmon_device_register_with_groups, however the patch itself makes
+use of hwmon_device_register_with_groups instead. As the driver remove
+function was still dropped, the hwmon device is no longer unregistered
+on driver removal, leading to a resource leak.
+
+Signed-off-by: Jean Delvare <jdelvare@suse.de>
+Fixes: 454aee17f hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/emc1403.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/hwmon/emc1403.c
++++ b/drivers/hwmon/emc1403.c
+@@ -355,9 +355,9 @@ static int emc1403_probe(struct i2c_clie
+ if (id->driver_data)
+ data->groups[1] = &emc1404_group;
+
+- hwmon_dev = hwmon_device_register_with_groups(&client->dev,
+- client->name, data,
+- data->groups);
++ hwmon_dev = devm_hwmon_device_register_with_groups(&client->dev,
++ client->name, data,
++ data->groups);
+ if (IS_ERR(hwmon_dev))
+ return PTR_ERR(hwmon_dev);
+
--- /dev/null
+From 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 Mon Sep 17 00:00:00 2001
+From: Josef Gajdusek <atx@atx.name>
+Date: Mon, 12 May 2014 13:48:26 +0200
+Subject: hwmon: (emc1403) Support full range of known chip revision numbers
+
+From: Josef Gajdusek <atx@atx.name>
+
+commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 upstream.
+
+The datasheet for EMC1413/EMC1414, which is fully compatible to
+EMC1403/1404 and uses the same chip identification, references revision
+numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers
+from 0x01 to 0x04 to make sure none are missed.
+
+Signed-off-by: Josef Gajdusek <atx@atx.name>
+[Guenter Roeck: Updated headline and description]
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/emc1403.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hwmon/emc1403.c
++++ b/drivers/hwmon/emc1403.c
+@@ -330,7 +330,7 @@ static int emc1403_detect(struct i2c_cli
+ }
+
+ id = i2c_smbus_read_byte_data(client, THERMAL_REVISION_REG);
+- if (id != 0x01)
++ if (id < 0x01 || id > 0x04)
+ return -ENODEV;
+
+ return 0;
--- /dev/null
+From da343fc776e0bcb238b65d9d24610819b95d0ef4 Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Fri, 18 Apr 2014 14:19:47 +0200
+Subject: irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit da343fc776e0bcb238b65d9d24610819b95d0ef4 upstream.
+
+The armada_370_xp_alloc_msi() function returns a signed int, which is
+negative on error. However, we store the return value into an
+irq_hw_number_t, which is unsigned. Therefore, we actually never test
+if armada_370_xp_alloc_msi() returns an error or not, which may lead
+us to use hwirq numbers of as 0xffffffe4 (when
+armada_370_xp_alloc_msi() returns -ENOSPC).
+
+This commit fixes that by storing the return value of
+armada_370_xp_alloc_msi() in a signed variable.
+
+Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support')
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Link: https://lkml.kernel.org/r/1397823593-1932-2-git-send-email-thomas.petazzoni@free-electrons.com
+Tested-by: Neil Greatorex <neil@fatboyfat.co.uk>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-armada-370-xp.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-armada-370-xp.c
++++ b/drivers/irqchip/irq-armada-370-xp.c
+@@ -130,8 +130,7 @@ static int armada_370_xp_setup_msi_irq(s
+ struct msi_desc *desc)
+ {
+ struct msi_msg msg;
+- irq_hw_number_t hwirq;
+- int virq;
++ int virq, hwirq;
+
+ hwirq = armada_370_xp_alloc_msi();
+ if (hwirq < 0)
--- /dev/null
+From ff3c664505bf8a8334bca5045e87b85cfe4d2277 Mon Sep 17 00:00:00 2001
+From: Neil Greatorex <neil@fatboyfat.co.uk>
+Date: Fri, 18 Apr 2014 14:19:49 +0200
+Subject: irqchip: armada-370-xp: Fix releasing of MSIs
+
+From: Neil Greatorex <neil@fatboyfat.co.uk>
+
+commit ff3c664505bf8a8334bca5045e87b85cfe4d2277 upstream.
+
+Store the value of d->hwirq in a local variable as the real value is wiped out
+by calling irq_dispose_mapping. Without this patch, the armada_370_xp_free_msi
+function would always free MSI#0, no matter what was passed to it.
+
+Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support')
+Signed-off-by: Neil Greatorex <neil@fatboyfat.co.uk>
+Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-armada-370-xp.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/irqchip/irq-armada-370-xp.c
++++ b/drivers/irqchip/irq-armada-370-xp.c
+@@ -156,8 +156,10 @@ static void armada_370_xp_teardown_msi_i
+ unsigned int irq)
+ {
+ struct irq_data *d = irq_get_irq_data(irq);
++ unsigned long hwirq = d->hwirq;
++
+ irq_dispose_mapping(irq);
+- armada_370_xp_free_msi(d->hwirq);
++ armada_370_xp_free_msi(hwirq);
+ }
+
+ static int armada_370_xp_check_msi_device(struct msi_chip *chip, struct pci_dev *dev,
--- /dev/null
+From 830cbe4b7a918613276aa3d3b28d24410623f92c Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Fri, 18 Apr 2014 14:19:48 +0200
+Subject: irqchip: armada-370-xp: implement the ->check_device() msi_chip operation
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 830cbe4b7a918613276aa3d3b28d24410623f92c upstream.
+
+Until now, we were leaving the ->check_device() msi_chip operation
+empty, which leads the PCI core to believe that we support both MSI
+and MSI-X. In fact, we do not support MSI-X, so we have to tell this
+to the PCI core by providing an implementation of this operation.
+
+Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support')
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Link: https://lkml.kernel.org/r/1397823593-1932-3-git-send-email-thomas.petazzoni@free-electrons.com
+Tested-by: Neil Greatorex <neil@fatboyfat.co.uk>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-armada-370-xp.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/irqchip/irq-armada-370-xp.c
++++ b/drivers/irqchip/irq-armada-370-xp.c
+@@ -160,6 +160,15 @@ static void armada_370_xp_teardown_msi_i
+ armada_370_xp_free_msi(d->hwirq);
+ }
+
++static int armada_370_xp_check_msi_device(struct msi_chip *chip, struct pci_dev *dev,
++ int nvec, int type)
++{
++ /* We support MSI, but not MSI-X */
++ if (type == PCI_CAP_ID_MSI)
++ return 0;
++ return -EINVAL;
++}
++
+ static struct irq_chip armada_370_xp_msi_irq_chip = {
+ .name = "armada_370_xp_msi_irq",
+ .irq_enable = unmask_msi_irq,
+@@ -198,6 +207,7 @@ static int armada_370_xp_msi_init(struct
+
+ msi_chip->setup_irq = armada_370_xp_setup_msi_irq;
+ msi_chip->teardown_irq = armada_370_xp_teardown_msi_irq;
++ msi_chip->check_device = armada_370_xp_check_msi_device;
+ msi_chip->of_node = node;
+
+ armada_370_xp_msi_domain =
--- /dev/null
+From 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Tue, 6 May 2014 09:36:08 +1000
+Subject: md: avoid possible spinning md thread at shutdown.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream.
+
+If an md array with externally managed metadata (e.g. DDF or IMSM)
+is in use, then we should not set safemode==2 at shutdown because:
+
+1/ this is ineffective: user-space need to be involved in any 'safemode' handling,
+2/ The safemode management code doesn't cope with safemode==2 on external metadata
+ and md_check_recover enters an infinite loop.
+
+Even at shutdown, an infinite-looping process can be problematic, so this
+could cause shutdown to hang.
+
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -8530,7 +8530,8 @@ static int md_notify_reboot(struct notif
+ if (mddev_trylock(mddev)) {
+ if (mddev->pers)
+ __md_stop_writes(mddev);
+- mddev->safemode = 2;
++ if (mddev->persistent)
++ mddev->safemode = 2;
+ mddev_unlock(mddev);
+ }
+ need_delay = 1;
--- /dev/null
+From cc13b1d1500656a20e41960668f3392dda9fa6e2 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Mon, 5 May 2014 13:34:37 +1000
+Subject: md/raid10: call wait_barrier() for each request submitted.
+
+From: NeilBrown <neilb@suse.de>
+
+commit cc13b1d1500656a20e41960668f3392dda9fa6e2 upstream.
+
+wait_barrier() includes a counter, so we must call it precisely once
+(unless balanced by allow_barrier()) for each request submitted.
+
+Since
+commit 20d0189b1012a37d2533a87fb451f7852f2418d1
+ block: Introduce new bio_split()
+in 3.14-rc1, we don't call it for the extra requests generated when
+we need to split a bio.
+
+When this happens the counter goes negative, any resync/recovery will
+never start, and "mdadm --stop" will hang.
+
+Reported-by: Chris Murphy <lists@colorremedies.com>
+Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1
+Cc: Kent Overstreet <kmo@daterainc.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid10.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -1172,6 +1172,13 @@ static void __make_request(struct mddev
+ int max_sectors;
+ int sectors;
+
++ /*
++ * Register the new request and wait if the reconstruction
++ * thread has put up a bar for new requests.
++ * Continue immediately if no resync is active currently.
++ */
++ wait_barrier(conf);
++
+ sectors = bio_sectors(bio);
+ while (test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) &&
+ bio->bi_iter.bi_sector < conf->reshape_progress &&
+@@ -1552,12 +1559,6 @@ static void make_request(struct mddev *m
+
+ md_write_start(mddev, bio);
+
+- /*
+- * Register the new request and wait if the reconstruction
+- * thread has put up a bar for new requests.
+- * Continue immediately if no resync is active currently.
+- */
+- wait_barrier(conf);
+
+ do {
+
--- /dev/null
+From 79465d2fd48e68940c2bdecddbdecd45bbba06fe Mon Sep 17 00:00:00 2001
+From: Rusty Russell <rusty@rustcorp.com.au>
+Date: Mon, 28 Apr 2014 11:05:43 +0930
+Subject: module: remove warning about waiting module removal.
+
+From: Rusty Russell <rusty@rustcorp.com.au>
+
+commit 79465d2fd48e68940c2bdecddbdecd45bbba06fe upstream.
+
+We remove the waiting module removal in commit 3f2b9c9cdf38 (September
+2013), but it turns out that modprobe in kmod (< version 16) was
+asking for waiting module removal. No one noticed since modprobe would
+check for 0 usage immediately before trying to remove the module, and
+the race is unlikely.
+
+However, it means that anyone running old (but not ancient) kmod
+versions is hitting the printk designed to see if anyone was running
+"rmmod -w". All reports so far have been false positives, so remove
+the warning.
+
+Fixes: 3f2b9c9cdf389e303b2273679af08aab5f153517
+Reported-by: Valerio Vanni <valerio.vanni@inwind.it>
+Cc: Elliott, Robert (Server Storage) <Elliott@hp.com>
+Acked-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/module.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/kernel/module.c
++++ b/kernel/module.c
+@@ -815,9 +815,6 @@ SYSCALL_DEFINE2(delete_module, const cha
+ return -EFAULT;
+ name[MODULE_NAME_LEN-1] = '\0';
+
+- if (!(flags & O_NONBLOCK))
+- pr_warn("waiting module removal not supported: please upgrade\n");
+-
+ if (mutex_lock_interruptible(&module_mutex) != 0)
+ return -EINTR;
+
--- /dev/null
+From a8d22396302b7e4e5f0a594c1c1594388c29edaf Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Wed, 30 Apr 2014 22:36:33 +0200
+Subject: PNP / ACPI: Do not return errors if _DIS or _SRS are not present
+
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+
+commit a8d22396302b7e4e5f0a594c1c1594388c29edaf upstream.
+
+The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
+and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
+present, respectively, but it should not do that, because those
+methods are optional. For this reason, modify pnpacpi_set_resources()
+and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
+or _DIS.
+
+This problem has been uncovered by commit 202317a573b2 (ACPI / scan:
+Add acpi_device objects for all device nodes in the namespace) and
+manifested itself by causing serial port suspend to fail on some
+systems.
+
+Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
+References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
+Reported-by: wxg4net <wxg4net@gmail.com>
+Reported-and-tested-by: <nonproffessional@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pnp/pnpacpi/core.c | 44 ++++++++++++++++++++++++++------------------
+ 1 file changed, 26 insertions(+), 18 deletions(-)
+
+--- a/drivers/pnp/pnpacpi/core.c
++++ b/drivers/pnp/pnpacpi/core.c
+@@ -83,8 +83,7 @@ static int pnpacpi_set_resources(struct
+ {
+ struct acpi_device *acpi_dev;
+ acpi_handle handle;
+- struct acpi_buffer buffer;
+- int ret;
++ int ret = 0;
+
+ pnp_dbg(&dev->dev, "set resources\n");
+
+@@ -97,19 +96,26 @@ static int pnpacpi_set_resources(struct
+ if (WARN_ON_ONCE(acpi_dev != dev->data))
+ dev->data = acpi_dev;
+
+- ret = pnpacpi_build_resource_template(dev, &buffer);
+- if (ret)
+- return ret;
+- ret = pnpacpi_encode_resources(dev, &buffer);
+- if (ret) {
++ if (acpi_has_method(handle, METHOD_NAME__SRS)) {
++ struct acpi_buffer buffer;
++
++ ret = pnpacpi_build_resource_template(dev, &buffer);
++ if (ret)
++ return ret;
++
++ ret = pnpacpi_encode_resources(dev, &buffer);
++ if (!ret) {
++ acpi_status status;
++
++ status = acpi_set_current_resources(handle, &buffer);
++ if (ACPI_FAILURE(status))
++ ret = -EIO;
++ }
+ kfree(buffer.pointer);
+- return ret;
+ }
+- if (ACPI_FAILURE(acpi_set_current_resources(handle, &buffer)))
+- ret = -EINVAL;
+- else if (acpi_bus_power_manageable(handle))
++ if (!ret && acpi_bus_power_manageable(handle))
+ ret = acpi_bus_set_power(handle, ACPI_STATE_D0);
+- kfree(buffer.pointer);
++
+ return ret;
+ }
+
+@@ -117,7 +123,7 @@ static int pnpacpi_disable_resources(str
+ {
+ struct acpi_device *acpi_dev;
+ acpi_handle handle;
+- int ret;
++ acpi_status status;
+
+ dev_dbg(&dev->dev, "disable resources\n");
+
+@@ -128,13 +134,15 @@ static int pnpacpi_disable_resources(str
+ }
+
+ /* acpi_unregister_gsi(pnp_irq(dev, 0)); */
+- ret = 0;
+ if (acpi_bus_power_manageable(handle))
+ acpi_bus_set_power(handle, ACPI_STATE_D3_COLD);
+- /* continue even if acpi_bus_set_power() fails */
+- if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DIS", NULL, NULL)))
+- ret = -ENODEV;
+- return ret;
++
++ /* continue even if acpi_bus_set_power() fails */
++ status = acpi_evaluate_object(handle, "_DIS", NULL, NULL);
++ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
++ return -ENODEV;
++
++ return 0;
+ }
+
+ #ifdef CONFIG_ACPI_SLEEP
--- /dev/null
+From c0940e95f7a78be0525c8d31df0b1f71e149e57e Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Wed, 30 Apr 2014 14:08:14 -0700
+Subject: Revert "hwmon: (coretemp) Refine TjMax detection"
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit c0940e95f7a78be0525c8d31df0b1f71e149e57e upstream.
+
+This reverts commit 9fb6c9c73b11bef65ba80a362547fd116c1e1c9d.
+
+Tjmax on some Intel CPUs is below 85 degrees C. One known example is
+L5630 with Tjmax of 71 degrees C. There are other Xeon processors with
+Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming
+document states that the temperature target is in bits 23:16 of MSR 0x1a2
+(MSR_TEMPERATURE_TARGET), which is 8 bits, not 7.
+
+So even if turbostat uses similar checks to validate Tjmax, there is no
+evidence that the checks are actually required. On the contrary, the
+checks are known to cause problems and therefore need to be removed.
+
+This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071.
+
+Fixes: 9fb6c9c hwmon: (coretemp) Refine TjMax detection
+Reviewed-by: Jean Delvare <jdelvare@suse.de>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/coretemp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/hwmon/coretemp.c
++++ b/drivers/hwmon/coretemp.c
+@@ -369,12 +369,12 @@ static int get_tjmax(struct cpuinfo_x86
+ if (cpu_has_tjmax(c))
+ dev_warn(dev, "Unable to read TjMax from CPU %u\n", id);
+ } else {
+- val = (eax >> 16) & 0x7f;
++ val = (eax >> 16) & 0xff;
+ /*
+ * If the TjMax is not plausible, an assumption
+ * will be used
+ */
+- if (val >= 85) {
++ if (val) {
+ dev_dbg(dev, "TjMax is %d degrees C\n", val);
+ return val * 1000;
+ }
arm64-fix-pud_huge-for-2-level-pagetables.patch
hwpoison-hugetlb-lock_page-unlock_page-does-not-match-for-handling-a-free-hugepage.patch
iwlwifi-mvm-delay-enabling-smart-fifo-until-after-beacon-rx.patch
+aio-fix-potential-leak-in-aio_run_iocb.patch
+module-remove-warning-about-waiting-module-removal.patch
+revert-hwmon-coretemp-refine-tjmax-detection.patch
+hwmon-emc1403-fix-inverted-store_hyst.patch
+hwmon-emc1403-fix-resource-leak-on-module-unload.patch
+hwmon-emc1403-support-full-range-of-known-chip-revision-numbers.patch
+drivercore-deferral-race-condition-fix.patch
+hrtimer-prevent-all-reprogramming-if-hang-detected.patch
+hrtimer-prevent-remote-enqueue-of-leftmost-timers.patch
+hrtimer-set-expiry-time-before-switch_hrtimer_base.patch
+dm-verity-fix-biovecs-hash-calculation-regression.patch
+dm-cache-fix-writethrough-mode-quiescing-in-cache_map.patch
+md-raid10-call-wait_barrier-for-each-request-submitted.patch
+md-avoid-possible-spinning-md-thread-at-shutdown.patch
+pnp-acpi-do-not-return-errors-if-_dis-or-_srs-are-not-present.patch
+acpi-ec-process-rather-than-discard-events-in-acpi_ec_clear.patch
+irqchip-armada-370-xp-fix-invalid-cast-of-signed-value-into-unsigned-variable.patch
+irqchip-armada-370-xp-implement-the-check_device-msi_chip-operation.patch
+irqchip-armada-370-xp-fix-releasing-of-msis.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
