From: Greg Kroah-Hartman Date: Tue, 3 Jun 2014 20:48:36 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v3.14.6~78 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ea1a09c2166e2b2bae33fd6446cfbb55918b6d35;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: acpi-ec-process-rather-than-discard-events-in-acpi_ec_clear.patch aio-fix-potential-leak-in-aio_run_iocb.patch dm-cache-fix-writethrough-mode-quiescing-in-cache_map.patch dm-verity-fix-biovecs-hash-calculation-regression.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 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 irqchip-armada-370-xp-fix-invalid-cast-of-signed-value-into-unsigned-variable.patch irqchip-armada-370-xp-fix-releasing-of-msis.patch irqchip-armada-370-xp-implement-the-check_device-msi_chip-operation.patch md-avoid-possible-spinning-md-thread-at-shutdown.patch md-raid10-call-wait_barrier-for-each-request-submitted.patch module-remove-warning-about-waiting-module-removal.patch pnp-acpi-do-not-return-errors-if-_dis-or-_srs-are-not-present.patch revert-hwmon-coretemp-refine-tjmax-detection.patch --- diff --git a/queue-3.14/acpi-ec-process-rather-than-discard-events-in-acpi_ec_clear.patch b/queue-3.14/acpi-ec-process-rather-than-discard-events-in-acpi_ec_clear.patch new file mode 100644 index 00000000000..9b874a3ab2c --- /dev/null +++ b/queue-3.14/acpi-ec-process-rather-than-discard-events-in-acpi_ec_clear.patch @@ -0,0 +1,120 @@ +From 3eba563e280101209bad27d40bfc83ddf1489234 Mon Sep 17 00:00:00 2001 +From: Kieran Clancy +Date: Wed, 30 Apr 2014 00:21:20 +0930 +Subject: ACPI / EC: Process rather than discard events in acpi_ec_clear + +From: Kieran Clancy + +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 +Signed-off-by: Kieran Clancy +Tested-by: Stefan Biereigel +Tested-by: Dennis Jansen +Tested-by: Nicolas Porcel +Tested-by: Maurizio D'Addona +Tested-by: Juan Manuel Cabo +Tested-by: Giannis Koutsou +Tested-by: Kieran Clancy +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-3.14/aio-fix-potential-leak-in-aio_run_iocb.patch b/queue-3.14/aio-fix-potential-leak-in-aio_run_iocb.patch new file mode 100644 index 00000000000..51b8775b31f --- /dev/null +++ b/queue-3.14/aio-fix-potential-leak-in-aio_run_iocb.patch @@ -0,0 +1,37 @@ +From 754320d6e166d3a12cb4810a452bde00afbd4e9a Mon Sep 17 00:00:00 2001 +From: Leon Yu +Date: Thu, 1 May 2014 03:31:28 +0000 +Subject: aio: fix potential leak in aio_run_iocb(). + +From: Leon Yu + +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 +Signed-off-by: Benjamin LaHaise +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.14/dm-cache-fix-writethrough-mode-quiescing-in-cache_map.patch b/queue-3.14/dm-cache-fix-writethrough-mode-quiescing-in-cache_map.patch new file mode 100644 index 00000000000..41bc32bf70a --- /dev/null +++ b/queue-3.14/dm-cache-fix-writethrough-mode-quiescing-in-cache_map.patch @@ -0,0 +1,33 @@ +From 131cd131a9ff63d4b84f3fe15073a2984ac30066 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Thu, 1 May 2014 16:14:24 -0400 +Subject: dm cache: fix writethrough mode quiescing in cache_map + +From: Mike Snitzer + +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 +Acked-by: Joe Thornber +Signed-off-by: Greg Kroah-Hartman + +--- + 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)) diff --git a/queue-3.14/dm-verity-fix-biovecs-hash-calculation-regression.patch b/queue-3.14/dm-verity-fix-biovecs-hash-calculation-regression.patch new file mode 100644 index 00000000000..9ef8b704380 --- /dev/null +++ b/queue-3.14/dm-verity-fix-biovecs-hash-calculation-regression.patch @@ -0,0 +1,65 @@ +From 3a7745215e7f73a5c7d9bcdc50661a55b39052a3 Mon Sep 17 00:00:00 2001 +From: Milan Broz +Date: Mon, 14 Apr 2014 22:02:30 +0200 +Subject: dm verity: fix biovecs hash calculation regression + +From: Milan Broz + +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 +Acked-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.14/drivercore-deferral-race-condition-fix.patch b/queue-3.14/drivercore-deferral-race-condition-fix.patch new file mode 100644 index 00000000000..06556cbd953 --- /dev/null +++ b/queue-3.14/drivercore-deferral-race-condition-fix.patch @@ -0,0 +1,123 @@ +From 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 Mon Sep 17 00:00:00 2001 +From: Grant Likely +Date: Tue, 29 Apr 2014 12:05:22 +0100 +Subject: drivercore: deferral race condition fix + +From: Grant Likely + +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 +Reviewed-by: Peter Ujfalusi +Tested-by: Peter Ujfalusi +Acked-by: Greg Kroah-Hartman +Cc: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.14/hrtimer-prevent-all-reprogramming-if-hang-detected.patch b/queue-3.14/hrtimer-prevent-all-reprogramming-if-hang-detected.patch new file mode 100644 index 00000000000..9c78b578b8c --- /dev/null +++ b/queue-3.14/hrtimer-prevent-all-reprogramming-if-hang-detected.patch @@ -0,0 +1,77 @@ +From 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 Mon Sep 17 00:00:00 2001 +From: Stuart Hayes +Date: Tue, 29 Apr 2014 17:55:02 -0500 +Subject: hrtimer: Prevent all reprogramming if hang detected + +From: Stuart Hayes + +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 +Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } diff --git a/queue-3.14/hrtimer-prevent-remote-enqueue-of-leftmost-timers.patch b/queue-3.14/hrtimer-prevent-remote-enqueue-of-leftmost-timers.patch new file mode 100644 index 00000000000..f155c1a0eeb --- /dev/null +++ b/queue-3.14/hrtimer-prevent-remote-enqueue-of-leftmost-timers.patch @@ -0,0 +1,55 @@ +From 012a45e3f4af68e86d85cce060c6c2fed56498b2 Mon Sep 17 00:00:00 2001 +From: Leon Ma +Date: Wed, 30 Apr 2014 16:43:10 +0800 +Subject: hrtimer: Prevent remote enqueue of leftmost timers + +From: Leon Ma + +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 +Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-3.14/hrtimer-set-expiry-time-before-switch_hrtimer_base.patch b/queue-3.14/hrtimer-set-expiry-time-before-switch_hrtimer_base.patch new file mode 100644 index 00000000000..90a175e8dbd --- /dev/null +++ b/queue-3.14/hrtimer-set-expiry-time-before-switch_hrtimer_base.patch @@ -0,0 +1,59 @@ +From 84ea7fe37908254c3bd90910921f6e1045c1747a Mon Sep 17 00:00:00 2001 +From: Viresh Kumar +Date: Mon, 12 May 2014 13:42:29 +0530 +Subject: hrtimer: Set expiry time before switch_hrtimer_base() + +From: Viresh Kumar + +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 +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.14/hwmon-emc1403-fix-inverted-store_hyst.patch b/queue-3.14/hwmon-emc1403-fix-inverted-store_hyst.patch new file mode 100644 index 00000000000..ebcae03ca3c --- /dev/null +++ b/queue-3.14/hwmon-emc1403-fix-inverted-store_hyst.patch @@ -0,0 +1,34 @@ +From 17c048fc4bd95efea208a1920f169547d8588f1f Mon Sep 17 00:00:00 2001 +From: Josef Gajdusek +Date: Sun, 11 May 2014 14:40:44 +0200 +Subject: hwmon: (emc1403) fix inverted store_hyst() + +From: Josef Gajdusek + +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 +Reviewed-by: Jean Delvare +[Guenter Roeck: Updated headline and description] +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.14/hwmon-emc1403-fix-resource-leak-on-module-unload.patch b/queue-3.14/hwmon-emc1403-fix-resource-leak-on-module-unload.patch new file mode 100644 index 00000000000..78d8cb366e8 --- /dev/null +++ b/queue-3.14/hwmon-emc1403-fix-resource-leak-on-module-unload.patch @@ -0,0 +1,40 @@ +From 8759f9046550f463098148bf577ccd32cdb895e3 Mon Sep 17 00:00:00 2001 +From: Jean Delvare +Date: Mon, 12 May 2014 11:44:51 +0200 +Subject: hwmon: (emc1403) Fix resource leak on module unload + +From: Jean Delvare + +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 +Fixes: 454aee17f hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups +Cc: Guenter Roeck +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-3.14/hwmon-emc1403-support-full-range-of-known-chip-revision-numbers.patch b/queue-3.14/hwmon-emc1403-support-full-range-of-known-chip-revision-numbers.patch new file mode 100644 index 00000000000..1ea8c2010e5 --- /dev/null +++ b/queue-3.14/hwmon-emc1403-support-full-range-of-known-chip-revision-numbers.patch @@ -0,0 +1,34 @@ +From 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 Mon Sep 17 00:00:00 2001 +From: Josef Gajdusek +Date: Mon, 12 May 2014 13:48:26 +0200 +Subject: hwmon: (emc1403) Support full range of known chip revision numbers + +From: Josef Gajdusek + +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 +[Guenter Roeck: Updated headline and description] +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.14/irqchip-armada-370-xp-fix-invalid-cast-of-signed-value-into-unsigned-variable.patch b/queue-3.14/irqchip-armada-370-xp-fix-invalid-cast-of-signed-value-into-unsigned-variable.patch new file mode 100644 index 00000000000..09d71dd389d --- /dev/null +++ b/queue-3.14/irqchip-armada-370-xp-fix-invalid-cast-of-signed-value-into-unsigned-variable.patch @@ -0,0 +1,42 @@ +From da343fc776e0bcb238b65d9d24610819b95d0ef4 Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni +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 + +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 +Link: https://lkml.kernel.org/r/1397823593-1932-2-git-send-email-thomas.petazzoni@free-electrons.com +Tested-by: Neil Greatorex +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-3.14/irqchip-armada-370-xp-fix-releasing-of-msis.patch b/queue-3.14/irqchip-armada-370-xp-fix-releasing-of-msis.patch new file mode 100644 index 00000000000..e3d02e3bee9 --- /dev/null +++ b/queue-3.14/irqchip-armada-370-xp-fix-releasing-of-msis.patch @@ -0,0 +1,39 @@ +From ff3c664505bf8a8334bca5045e87b85cfe4d2277 Mon Sep 17 00:00:00 2001 +From: Neil Greatorex +Date: Fri, 18 Apr 2014 14:19:49 +0200 +Subject: irqchip: armada-370-xp: Fix releasing of MSIs + +From: Neil Greatorex + +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 +Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com +Signed-off-by: Thomas Petazzoni +Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-3.14/irqchip-armada-370-xp-implement-the-check_device-msi_chip-operation.patch b/queue-3.14/irqchip-armada-370-xp-implement-the-check_device-msi_chip-operation.patch new file mode 100644 index 00000000000..03a19868e07 --- /dev/null +++ b/queue-3.14/irqchip-armada-370-xp-implement-the-check_device-msi_chip-operation.patch @@ -0,0 +1,51 @@ +From 830cbe4b7a918613276aa3d3b28d24410623f92c Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni +Date: Fri, 18 Apr 2014 14:19:48 +0200 +Subject: irqchip: armada-370-xp: implement the ->check_device() msi_chip operation + +From: Thomas Petazzoni + +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 +Link: https://lkml.kernel.org/r/1397823593-1932-3-git-send-email-thomas.petazzoni@free-electrons.com +Tested-by: Neil Greatorex +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + 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 = diff --git a/queue-3.14/md-avoid-possible-spinning-md-thread-at-shutdown.patch b/queue-3.14/md-avoid-possible-spinning-md-thread-at-shutdown.patch new file mode 100644 index 00000000000..e7e6d5d554c --- /dev/null +++ b/queue-3.14/md-avoid-possible-spinning-md-thread-at-shutdown.patch @@ -0,0 +1,38 @@ +From 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Tue, 6 May 2014 09:36:08 +1000 +Subject: md: avoid possible spinning md thread at shutdown. + +From: NeilBrown + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.14/md-raid10-call-wait_barrier-for-each-request-submitted.patch b/queue-3.14/md-raid10-call-wait_barrier-for-each-request-submitted.patch new file mode 100644 index 00000000000..b4929b0ec5a --- /dev/null +++ b/queue-3.14/md-raid10-call-wait_barrier-for-each-request-submitted.patch @@ -0,0 +1,60 @@ +From cc13b1d1500656a20e41960668f3392dda9fa6e2 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Mon, 5 May 2014 13:34:37 +1000 +Subject: md/raid10: call wait_barrier() for each request submitted. + +From: NeilBrown + +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 +Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 +Cc: Kent Overstreet +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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 { + diff --git a/queue-3.14/module-remove-warning-about-waiting-module-removal.patch b/queue-3.14/module-remove-warning-about-waiting-module-removal.patch new file mode 100644 index 00000000000..84d6168c509 --- /dev/null +++ b/queue-3.14/module-remove-warning-about-waiting-module-removal.patch @@ -0,0 +1,43 @@ +From 79465d2fd48e68940c2bdecddbdecd45bbba06fe Mon Sep 17 00:00:00 2001 +From: Rusty Russell +Date: Mon, 28 Apr 2014 11:05:43 +0930 +Subject: module: remove warning about waiting module removal. + +From: Rusty Russell + +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 +Cc: Elliott, Robert (Server Storage) +Acked-by: Lucas De Marchi +Signed-off-by: Rusty Russell +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-3.14/pnp-acpi-do-not-return-errors-if-_dis-or-_srs-are-not-present.patch b/queue-3.14/pnp-acpi-do-not-return-errors-if-_dis-or-_srs-are-not-present.patch new file mode 100644 index 00000000000..a88b89770f7 --- /dev/null +++ b/queue-3.14/pnp-acpi-do-not-return-errors-if-_dis-or-_srs-are-not-present.patch @@ -0,0 +1,111 @@ +From a8d22396302b7e4e5f0a594c1c1594388c29edaf Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +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" + +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 +Reported-and-tested-by: +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.14/revert-hwmon-coretemp-refine-tjmax-detection.patch b/queue-3.14/revert-hwmon-coretemp-refine-tjmax-detection.patch new file mode 100644 index 00000000000..14726c95ccc --- /dev/null +++ b/queue-3.14/revert-hwmon-coretemp-refine-tjmax-detection.patch @@ -0,0 +1,49 @@ +From c0940e95f7a78be0525c8d31df0b1f71e149e57e Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Wed, 30 Apr 2014 14:08:14 -0700 +Subject: Revert "hwmon: (coretemp) Refine TjMax detection" + +From: Guenter Roeck + +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 +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-3.14/series b/queue-3.14/series index b897068f192..28d72baf308 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -40,3 +40,22 @@ x86-mm-hugetlb-add-missing-tlb-page-invalidation-for-hugetlb_cow.patch 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