From: Greg Kroah-Hartman Date: Wed, 4 Jun 2014 22:57:58 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v3.14.6~34 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4e1cf5c26a3331cbad26c24ca89e3a8fe0fca1aa;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: clk-fix-double-free-due-to-devm_clk_register.patch clk-fix-slab-corruption-in-clk_unregister.patch crypto-caam-add-allocation-failure-handling-in-sprintfcat-macro.patch crypto-s390-fix-aes-des-ctr-mode-concurrency-finding.patch intel_pstate-remove-setting-p-state-to-max-on-init.patch intel_pstate-set-turbo-vid-for-baytrail.patch iommu-amd-fix-interrupt-remapping-for-aliased-devices.patch libceph-fix-corruption-when-using-page_count-0-page-in-rbd.patch media-fc2580-fix-tuning-failure-on-32-bit-arch.patch powerpc-fix-64-bit-builds-with-binutils-2.24.patch powerpc-irq-work-racing-with-timer-interrupt-can-result-in-timer-interrupt-hang.patch powerpc-kexec-fix-processor-x-is-stuck-issue-during-kexec-from-st-mode.patch powerpc-powernv-reset-root-port-in-firmware.patch spi-core-ignore-unsupported-dual-quad-transfer-mode-bits.patch --- diff --git a/queue-3.14/clk-fix-double-free-due-to-devm_clk_register.patch b/queue-3.14/clk-fix-double-free-due-to-devm_clk_register.patch new file mode 100644 index 00000000000..567b57e060a --- /dev/null +++ b/queue-3.14/clk-fix-double-free-due-to-devm_clk_register.patch @@ -0,0 +1,163 @@ +From 293ba3b4a4fd54891b900f2911d1a57e1ed4a843 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Fri, 18 Apr 2014 16:29:42 -0700 +Subject: clk: Fix double free due to devm_clk_register() + +From: Stephen Boyd + +commit 293ba3b4a4fd54891b900f2911d1a57e1ed4a843 upstream. + +Now that clk_unregister() frees the struct clk we're +unregistering we'll free memory twice: first we'll call kfree() +in __clk_release() with an address kmalloc doesn't know about and +second we'll call kfree() in the devres layer. Remove the +allocation of struct clk in devm_clk_register() and let +clk_release() handle it. This fixes slab errors like: + +============================================================================= +BUG kmalloc-128 (Not tainted): Invalid object pointer 0xed08e8d0 +----------------------------------------------------------------------------- + +Disabling lock debugging due to kernel taint +INFO: Slab 0xeec503f8 objects=25 used=15 fp=0xed08ea00 flags=0x4081 +CPU: 2 PID: 73 Comm: rmmod Tainted: G B 3.14.0-11032-g526e9c764381 #34 +[] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[] (show_stack) from [] (dump_stack+0x70/0xbc) +[] (dump_stack) from [] (slab_err+0x74/0x84) +[] (slab_err) from [] (free_debug_processing+0x2cc/0x31c) +[] (free_debug_processing) from [] (__slab_free+0x38/0x41c) +[] (__slab_free) from [] (clk_unregister+0xd4/0x140) +[] (clk_unregister) from [] (release_nodes+0x164/0x1d8) +[] (release_nodes) from [] (__device_release_driver+0x60/0xb0) +[] (__device_release_driver) from [] (driver_detach+0xb4/0xb8) +[] (driver_detach) from [] (bus_remove_driver+0x5c/0xc4) +[] (bus_remove_driver) from [] (SyS_delete_module+0x148/0x1d8) +[] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x48) +FIX kmalloc-128: Object at 0xed08e8d0 not freed + +Fixes: fcb0ee6a3d33 (clk: Implement clk_unregister) +Cc: Jiada Wang +Cc: Sylwester Nawrocki +Cc: Kyungmin Park +Signed-off-by: Stephen Boyd +Signed-off-by: Mike Turquette +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/clk.c | 71 ++++++++++++++++++++++-------------------------------- + 1 file changed, 30 insertions(+), 41 deletions(-) + +--- a/drivers/clk/clk.c ++++ b/drivers/clk/clk.c +@@ -1977,9 +1977,28 @@ struct clk *__clk_register(struct device + } + EXPORT_SYMBOL_GPL(__clk_register); + +-static int _clk_register(struct device *dev, struct clk_hw *hw, struct clk *clk) ++/** ++ * clk_register - allocate a new clock, register it and return an opaque cookie ++ * @dev: device that is registering this clock ++ * @hw: link to hardware-specific clock data ++ * ++ * clk_register is the primary interface for populating the clock tree with new ++ * clock nodes. It returns a pointer to the newly allocated struct clk which ++ * cannot be dereferenced by driver code but may be used in conjuction with the ++ * rest of the clock API. In the event of an error clk_register will return an ++ * error code; drivers must test for an error code after calling clk_register. ++ */ ++struct clk *clk_register(struct device *dev, struct clk_hw *hw) + { + int i, ret; ++ struct clk *clk; ++ ++ clk = kzalloc(sizeof(*clk), GFP_KERNEL); ++ if (!clk) { ++ pr_err("%s: could not allocate clk\n", __func__); ++ ret = -ENOMEM; ++ goto fail_out; ++ } + + clk->name = kstrdup(hw->init->name, GFP_KERNEL); + if (!clk->name) { +@@ -2019,7 +2038,7 @@ static int _clk_register(struct device * + + ret = __clk_init(dev, clk); + if (!ret) +- return 0; ++ return clk; + + fail_parent_names_copy: + while (--i >= 0) +@@ -2028,36 +2047,6 @@ fail_parent_names_copy: + fail_parent_names: + kfree(clk->name); + fail_name: +- return ret; +-} +- +-/** +- * clk_register - allocate a new clock, register it and return an opaque cookie +- * @dev: device that is registering this clock +- * @hw: link to hardware-specific clock data +- * +- * clk_register is the primary interface for populating the clock tree with new +- * clock nodes. It returns a pointer to the newly allocated struct clk which +- * cannot be dereferenced by driver code but may be used in conjuction with the +- * rest of the clock API. In the event of an error clk_register will return an +- * error code; drivers must test for an error code after calling clk_register. +- */ +-struct clk *clk_register(struct device *dev, struct clk_hw *hw) +-{ +- int ret; +- struct clk *clk; +- +- clk = kzalloc(sizeof(*clk), GFP_KERNEL); +- if (!clk) { +- pr_err("%s: could not allocate clk\n", __func__); +- ret = -ENOMEM; +- goto fail_out; +- } +- +- ret = _clk_register(dev, hw, clk); +- if (!ret) +- return clk; +- + kfree(clk); + fail_out: + return ERR_PTR(ret); +@@ -2166,7 +2155,7 @@ EXPORT_SYMBOL_GPL(clk_unregister); + + static void devm_clk_release(struct device *dev, void *res) + { +- clk_unregister(res); ++ clk_unregister(*(struct clk **)res); + } + + /** +@@ -2181,18 +2170,18 @@ static void devm_clk_release(struct devi + struct clk *devm_clk_register(struct device *dev, struct clk_hw *hw) + { + struct clk *clk; +- int ret; ++ struct clk **clkp; + +- clk = devres_alloc(devm_clk_release, sizeof(*clk), GFP_KERNEL); +- if (!clk) ++ clkp = devres_alloc(devm_clk_release, sizeof(*clkp), GFP_KERNEL); ++ if (!clkp) + return ERR_PTR(-ENOMEM); + +- ret = _clk_register(dev, hw, clk); +- if (!ret) { +- devres_add(dev, clk); ++ clk = clk_register(dev, hw); ++ if (!IS_ERR(clk)) { ++ *clkp = clk; ++ devres_add(dev, clkp); + } else { +- devres_free(clk); +- clk = ERR_PTR(ret); ++ devres_free(clkp); + } + + return clk; diff --git a/queue-3.14/clk-fix-slab-corruption-in-clk_unregister.patch b/queue-3.14/clk-fix-slab-corruption-in-clk_unregister.patch new file mode 100644 index 00000000000..1d4660ce55e --- /dev/null +++ b/queue-3.14/clk-fix-slab-corruption-in-clk_unregister.patch @@ -0,0 +1,102 @@ +From 874f224cc52d64c912087e68e3724be95ad80ee7 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Fri, 18 Apr 2014 16:29:43 -0700 +Subject: clk: Fix slab corruption in clk_unregister() + +From: Stephen Boyd + +commit 874f224cc52d64c912087e68e3724be95ad80ee7 upstream. + +When a clock is unregsitered, we iterate over the list of +children and reparent them to NULL (i.e. orphan list). While +iterating the list, we should use the safe iterators because the +children list for this clock is changing when we reparent the +children to NULL. Failure to iterate safely can lead to slab +corruption like this: + +============================================================================= +BUG kmalloc-128 (Not tainted): Poison overwritten +----------------------------------------------------------------------------- + +Disabling lock debugging due to kernel taint +INFO: 0xed0c4900-0xed0c4903. First byte 0x0 instead of 0x6b +INFO: Allocated in clk_register+0x20/0x1bc age=297 cpu=2 pid=70 + __slab_alloc.isra.39.constprop.42+0x410/0x454 + kmem_cache_alloc_trace+0x200/0x24c + clk_register+0x20/0x1bc + devm_clk_register+0x34/0x68 + 0xbf0000f0 + platform_drv_probe+0x18/0x48 + driver_probe_device+0x94/0x360 + __driver_attach+0x94/0x98 + bus_for_each_dev+0x54/0x88 + bus_add_driver+0xe8/0x204 + driver_register+0x78/0xf4 + do_one_initcall+0xc4/0x17c + load_module+0x19ac/0x2294 + SyS_init_module+0xa4/0x110 + ret_fast_syscall+0x0/0x48 +INFO: Freed in clk_unregister+0xd4/0x140 age=23 cpu=2 pid=73 + __slab_free+0x38/0x41c + clk_unregister+0xd4/0x140 + release_nodes+0x164/0x1d8 + __device_release_driver+0x60/0xb0 + driver_detach+0xb4/0xb8 + bus_remove_driver+0x5c/0xc4 + SyS_delete_module+0x148/0x1d8 + ret_fast_syscall+0x0/0x48 +INFO: Slab 0xeec50b90 objects=25 used=0 fp=0xed0c5400 flags=0x4080 +INFO: Object 0xed0c48c0 @offset=2240 fp=0xed0c4a00 + +Bytes b4 ed0c48b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ +Object ed0c48c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +Object ed0c48d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +Object ed0c48e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +Object ed0c48f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +Object ed0c4900: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk +Object ed0c4910: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +Object ed0c4920: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk +Object ed0c4930: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. +Redzone ed0c4940: bb bb bb bb .... +Padding ed0c49e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ +Padding ed0c49f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ +CPU: 3 PID: 75 Comm: mdev Tainted: G B 3.14.0-11033-g2054ba5ca781 #35 +[] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[] (show_stack) from [] (dump_stack+0x70/0xbc) +[] (dump_stack) from [] (check_bytes_and_report+0xbc/0x100) +[] (check_bytes_and_report) from [] (check_object+0x18c/0x218) +[] (check_object) from [] (__free_slab+0x104/0x144) +[] (__free_slab) from [] (__slab_free+0x3dc/0x41c) +[] (__slab_free) from [] (load_elf_binary+0x88/0x12b4) +[] (load_elf_binary) from [] (search_binary_handler+0x78/0x18c) +[] (search_binary_handler) from [] (do_execve+0x490/0x5dc) +[] (do_execve) from [] (____call_usermodehelper+0x134/0x168) +[] (____call_usermodehelper) from [] (ret_from_fork+0x14/0x2c) +FIX kmalloc-128: Restoring 0xed0c4900-0xed0c4903=0x6b + +Fixes: fcb0ee6a3d33 (clk: Implement clk_unregister) +Cc: Jiada Wang +Cc: Sylwester Nawrocki +Cc: Kyungmin Park +Signed-off-by: Stephen Boyd +Signed-off-by: Mike Turquette +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/clk.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/clk/clk.c ++++ b/drivers/clk/clk.c +@@ -2133,9 +2133,10 @@ void clk_unregister(struct clk *clk) + + if (!hlist_empty(&clk->children)) { + struct clk *child; ++ struct hlist_node *t; + + /* Reparent all children to the orphan list. */ +- hlist_for_each_entry(child, &clk->children, child_node) ++ hlist_for_each_entry_safe(child, t, &clk->children, child_node) + clk_set_parent(child, NULL); + } + diff --git a/queue-3.14/crypto-caam-add-allocation-failure-handling-in-sprintfcat-macro.patch b/queue-3.14/crypto-caam-add-allocation-failure-handling-in-sprintfcat-macro.patch new file mode 100644 index 00000000000..ef05f83fb8c --- /dev/null +++ b/queue-3.14/crypto-caam-add-allocation-failure-handling-in-sprintfcat-macro.patch @@ -0,0 +1,40 @@ +From 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 Mon Sep 17 00:00:00 2001 +From: Horia Geanta +Date: Fri, 18 Apr 2014 13:01:42 +0300 +Subject: crypto: caam - add allocation failure handling in SPRINTFCAT macro + +From: Horia Geanta + +commit 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 upstream. + +GFP_ATOMIC memory allocation could fail. +In this case, avoid NULL pointer dereference and notify user. + +Cc: Kim Phillips +Signed-off-by: Horia Geanta +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/caam/error.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/crypto/caam/error.c ++++ b/drivers/crypto/caam/error.c +@@ -16,9 +16,13 @@ + char *tmp; \ + \ + tmp = kmalloc(sizeof(format) + max_alloc, GFP_ATOMIC); \ +- sprintf(tmp, format, param); \ +- strcat(str, tmp); \ +- kfree(tmp); \ ++ if (likely(tmp)) { \ ++ sprintf(tmp, format, param); \ ++ strcat(str, tmp); \ ++ kfree(tmp); \ ++ } else { \ ++ strcat(str, "kmalloc failure in SPRINTFCAT"); \ ++ } \ + } + + static void report_jump_idx(u32 status, char *outstr) diff --git a/queue-3.14/crypto-s390-fix-aes-des-ctr-mode-concurrency-finding.patch b/queue-3.14/crypto-s390-fix-aes-des-ctr-mode-concurrency-finding.patch new file mode 100644 index 00000000000..ecfa780167f --- /dev/null +++ b/queue-3.14/crypto-s390-fix-aes-des-ctr-mode-concurrency-finding.patch @@ -0,0 +1,48 @@ +From 3901c1124ec5099254a9396085f7798153a7293f Mon Sep 17 00:00:00 2001 +From: Harald Freudenberger +Date: Wed, 7 May 2014 16:51:29 +0200 +Subject: crypto: s390 - fix aes,des ctr mode concurrency finding. + +From: Harald Freudenberger + +commit 3901c1124ec5099254a9396085f7798153a7293f upstream. + +An additional testcase found an issue with the last +series of patches applied: the fallback solution may +not save the iv value after operation. This very small +fix just makes sure the iv is copied back to the +walk/desc struct. + +Signed-off-by: Harald Freudenberger +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/crypto/aes_s390.c | 3 +++ + arch/s390/crypto/des_s390.c | 3 +++ + 2 files changed, 6 insertions(+) + +--- a/arch/s390/crypto/aes_s390.c ++++ b/arch/s390/crypto/aes_s390.c +@@ -820,6 +820,9 @@ static int ctr_aes_crypt(struct blkciphe + else + memcpy(walk->iv, ctrptr, AES_BLOCK_SIZE); + spin_unlock(&ctrblk_lock); ++ } else { ++ if (!nbytes) ++ memcpy(walk->iv, ctrptr, AES_BLOCK_SIZE); + } + /* + * final block may be < AES_BLOCK_SIZE, copy only nbytes +--- a/arch/s390/crypto/des_s390.c ++++ b/arch/s390/crypto/des_s390.c +@@ -429,6 +429,9 @@ static int ctr_desall_crypt(struct blkci + else + memcpy(walk->iv, ctrptr, DES_BLOCK_SIZE); + spin_unlock(&ctrblk_lock); ++ } else { ++ if (!nbytes) ++ memcpy(walk->iv, ctrptr, DES_BLOCK_SIZE); + } + /* final block may be < DES_BLOCK_SIZE, copy only nbytes */ + if (nbytes) { diff --git a/queue-3.14/intel_pstate-remove-setting-p-state-to-max-on-init.patch b/queue-3.14/intel_pstate-remove-setting-p-state-to-max-on-init.patch new file mode 100644 index 00000000000..c8af6da475b --- /dev/null +++ b/queue-3.14/intel_pstate-remove-setting-p-state-to-max-on-init.patch @@ -0,0 +1,66 @@ +From d40a63c45b506b0681918d7c62a15cc9d48c8681 Mon Sep 17 00:00:00 2001 +From: Dirk Brandewie +Date: Thu, 8 May 2014 12:57:24 -0700 +Subject: intel_pstate: remove setting P state to MAX on init + +From: Dirk Brandewie + +commit d40a63c45b506b0681918d7c62a15cc9d48c8681 upstream. + +Setting the P state of the core to max at init time is a hold over +from early implementation of intel_pstate where intel_pstate disabled +cpufreq and loaded VERY early in the boot sequence. This was to +ensure that intel_pstate did not affect boot time. This in not needed +now that intel_pstate is a cpufreq driver. + +Removing this covers the case where a CPU has gone through a manual +CPU offline/online cycle and the P state is set to MAX on init and the +CPU immediately goes idle. Due to HW coordination the P state request +on the idle CPU will drag all cores to MAX P state until the load is +reevaluated when to core goes non-idle. + +Reported-by: Patrick Marlier +Signed-off-by: Dirk Brandewie +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/intel_pstate.c | 13 +------------ + 1 file changed, 1 insertion(+), 12 deletions(-) + +--- a/drivers/cpufreq/intel_pstate.c ++++ b/drivers/cpufreq/intel_pstate.c +@@ -555,12 +555,7 @@ static void intel_pstate_get_cpu_pstates + + if (pstate_funcs.get_vid) + pstate_funcs.get_vid(cpu); +- +- /* +- * goto max pstate so we don't slow up boot if we are built-in if we are +- * a module we will take care of it during normal operation +- */ +- intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate); ++ intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate); + } + + static inline void intel_pstate_calc_busy(struct cpudata *cpu, +@@ -706,11 +701,6 @@ static int intel_pstate_init_cpu(unsigne + cpu = all_cpu_data[cpunum]; + + intel_pstate_get_cpu_pstates(cpu); +- if (!cpu->pstate.current_pstate) { +- all_cpu_data[cpunum] = NULL; +- kfree(cpu); +- return -ENODATA; +- } + + cpu->cpu = cpunum; + +@@ -721,7 +711,6 @@ static int intel_pstate_init_cpu(unsigne + cpu->timer.expires = jiffies + HZ/100; + intel_pstate_busy_pid_reset(cpu); + intel_pstate_sample(cpu); +- intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate); + + add_timer_on(&cpu->timer, cpunum); + diff --git a/queue-3.14/intel_pstate-set-turbo-vid-for-baytrail.patch b/queue-3.14/intel_pstate-set-turbo-vid-for-baytrail.patch new file mode 100644 index 00000000000..e62edd7f2f3 --- /dev/null +++ b/queue-3.14/intel_pstate-set-turbo-vid-for-baytrail.patch @@ -0,0 +1,91 @@ +From 21855ff5bcbdd075e1c99772827a84912ab083dd Mon Sep 17 00:00:00 2001 +From: Dirk Brandewie +Date: Thu, 8 May 2014 12:57:23 -0700 +Subject: intel_pstate: Set turbo VID for BayTrail + +From: Dirk Brandewie + +commit 21855ff5bcbdd075e1c99772827a84912ab083dd upstream. + +A documentation update exposed that there is a separate set of VID +values that must be used in the turbo/boost P state range. Add +enumerating and setting the correct VID for P states in the turbo +range. + +Signed-off-by: Dirk Brandewie +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/intel_pstate.c | 21 +++++++++++++++------ + 1 file changed, 15 insertions(+), 6 deletions(-) + +--- a/drivers/cpufreq/intel_pstate.c ++++ b/drivers/cpufreq/intel_pstate.c +@@ -37,6 +37,7 @@ + #define BYT_RATIOS 0x66a + #define BYT_VIDS 0x66b + #define BYT_TURBO_RATIOS 0x66c ++#define BYT_TURBO_VIDS 0x66d + + + #define FRAC_BITS 6 +@@ -70,8 +71,9 @@ struct pstate_data { + }; + + struct vid_data { +- int32_t min; +- int32_t max; ++ int min; ++ int max; ++ int turbo; + int32_t ratio; + }; + +@@ -360,14 +362,14 @@ static int byt_get_min_pstate(void) + { + u64 value; + rdmsrl(BYT_RATIOS, value); +- return (value >> 8) & 0xFF; ++ return (value >> 8) & 0x3F; + } + + static int byt_get_max_pstate(void) + { + u64 value; + rdmsrl(BYT_RATIOS, value); +- return (value >> 16) & 0xFF; ++ return (value >> 16) & 0x3F; + } + + static int byt_get_turbo_pstate(void) +@@ -394,6 +396,9 @@ static void byt_set_pstate(struct cpudat + vid_fp = clamp_t(int32_t, vid_fp, cpudata->vid.min, cpudata->vid.max); + vid = fp_toint(vid_fp); + ++ if (pstate > cpudata->pstate.max_pstate) ++ vid = cpudata->vid.turbo; ++ + val |= vid; + + wrmsrl(MSR_IA32_PERF_CTL, val); +@@ -403,13 +408,17 @@ static void byt_get_vid(struct cpudata * + { + u64 value; + ++ + rdmsrl(BYT_VIDS, value); +- cpudata->vid.min = int_tofp((value >> 8) & 0x7f); +- cpudata->vid.max = int_tofp((value >> 16) & 0x7f); ++ cpudata->vid.min = int_tofp((value >> 8) & 0x3f); ++ cpudata->vid.max = int_tofp((value >> 16) & 0x3f); + cpudata->vid.ratio = div_fp( + cpudata->vid.max - cpudata->vid.min, + int_tofp(cpudata->pstate.max_pstate - + cpudata->pstate.min_pstate)); ++ ++ rdmsrl(BYT_TURBO_VIDS, value); ++ cpudata->vid.turbo = value & 0x7f; + } + + diff --git a/queue-3.14/iommu-amd-fix-interrupt-remapping-for-aliased-devices.patch b/queue-3.14/iommu-amd-fix-interrupt-remapping-for-aliased-devices.patch new file mode 100644 index 00000000000..6fb4c20ac20 --- /dev/null +++ b/queue-3.14/iommu-amd-fix-interrupt-remapping-for-aliased-devices.patch @@ -0,0 +1,37 @@ +From e028a9e6b8a637af09ac4114083280df4a7045f1 Mon Sep 17 00:00:00 2001 +From: Alex Williamson +Date: Tue, 22 Apr 2014 10:08:40 -0600 +Subject: iommu/amd: Fix interrupt remapping for aliased devices + +From: Alex Williamson + +commit e028a9e6b8a637af09ac4114083280df4a7045f1 upstream. + +An apparent cut and paste error prevents the correct flags from being +set on the alias device resulting in MSI on conventional PCI devices +failing to work. This also produces error events from the IOMMU like: + +AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.4 address=0x000000fdf8000000 flags=0x0a00] + +Where 14.4 is a PCIe-to-PCI bridge with a device behind it trying to +use MSI interrupts. + +Signed-off-by: Alex Williamson +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/iommu/amd_iommu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iommu/amd_iommu.c ++++ b/drivers/iommu/amd_iommu.c +@@ -3999,7 +3999,7 @@ static struct irq_remap_table *get_irq_t + iommu_flush_dte(iommu, devid); + if (devid != alias) { + irq_lookup_table[alias] = table; +- set_dte_irq_entry(devid, table); ++ set_dte_irq_entry(alias, table); + iommu_flush_dte(iommu, alias); + } + diff --git a/queue-3.14/libceph-fix-corruption-when-using-page_count-0-page-in-rbd.patch b/queue-3.14/libceph-fix-corruption-when-using-page_count-0-page-in-rbd.patch new file mode 100644 index 00000000000..6464f869011 --- /dev/null +++ b/queue-3.14/libceph-fix-corruption-when-using-page_count-0-page-in-rbd.patch @@ -0,0 +1,70 @@ +From 178eda29ca721842f2146378e73d43e0044c4166 Mon Sep 17 00:00:00 2001 +From: Chunwei Chen +Date: Wed, 23 Apr 2014 12:35:09 +0800 +Subject: libceph: fix corruption when using page_count 0 page in rbd + +From: Chunwei Chen + +commit 178eda29ca721842f2146378e73d43e0044c4166 upstream. + +It has been reported that using ZFSonLinux on rbd will result in memory +corruption. The bug report can be found here: + +https://github.com/zfsonlinux/spl/issues/241 +http://tracker.ceph.com/issues/7790 + +The reason is that ZFS will send pages with page_count 0 into rbd, which in +turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with +page_count 0, as it will do get_page and put_page, and erroneously free the +page. + +This type of issue has been noted before, and handled in iscsi, drbd, +etc. So, rbd should also handle this. This fix address this issue by fall back +to slower sendmsg when page_count 0 detected. + +Cc: Sage Weil +Cc: Yehuda Sadeh +Signed-off-by: Chunwei Chen +Reviewed-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman + +--- + net/ceph/messenger.c | 20 +++++++++++++++++++- + 1 file changed, 19 insertions(+), 1 deletion(-) + +--- a/net/ceph/messenger.c ++++ b/net/ceph/messenger.c +@@ -557,7 +557,7 @@ static int ceph_tcp_sendmsg(struct socke + return r; + } + +-static int ceph_tcp_sendpage(struct socket *sock, struct page *page, ++static int __ceph_tcp_sendpage(struct socket *sock, struct page *page, + int offset, size_t size, bool more) + { + int flags = MSG_DONTWAIT | MSG_NOSIGNAL | (more ? MSG_MORE : MSG_EOR); +@@ -570,6 +570,24 @@ static int ceph_tcp_sendpage(struct sock + return ret; + } + ++static int ceph_tcp_sendpage(struct socket *sock, struct page *page, ++ int offset, size_t size, bool more) ++{ ++ int ret; ++ struct kvec iov; ++ ++ /* sendpage cannot properly handle pages with page_count == 0, ++ * we need to fallback to sendmsg if that's the case */ ++ if (page_count(page) >= 1) ++ return __ceph_tcp_sendpage(sock, page, offset, size, more); ++ ++ iov.iov_base = kmap(page) + offset; ++ iov.iov_len = size; ++ ret = ceph_tcp_sendmsg(sock, &iov, 1, size, more); ++ kunmap(page); ++ ++ return ret; ++} + + /* + * Shutdown/close the socket for the given connection. diff --git a/queue-3.14/media-fc2580-fix-tuning-failure-on-32-bit-arch.patch b/queue-3.14/media-fc2580-fix-tuning-failure-on-32-bit-arch.patch new file mode 100644 index 00000000000..6b4e4d5f725 --- /dev/null +++ b/queue-3.14/media-fc2580-fix-tuning-failure-on-32-bit-arch.patch @@ -0,0 +1,57 @@ +From 8845cc6415ec28ef8d57b3fb81c75ef9bce69c5f Mon Sep 17 00:00:00 2001 +From: Antti Palosaari +Date: Thu, 10 Apr 2014 21:18:16 -0300 +Subject: media: fc2580: fix tuning failure on 32-bit arch + +From: Antti Palosaari + +commit 8845cc6415ec28ef8d57b3fb81c75ef9bce69c5f upstream. + +There was some frequency calculation overflows which caused tuning +failure on 32-bit architecture. Use 64-bit numbers where needed in +order to avoid calculation overflows. + +Thanks for the Finnish person, who asked remain anonymous, reporting, +testing and suggesting the fix. + +Signed-off-by: Antti Palosaari +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/tuners/fc2580.c | 6 +++--- + drivers/media/tuners/fc2580_priv.h | 1 + + 2 files changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/media/tuners/fc2580.c ++++ b/drivers/media/tuners/fc2580.c +@@ -195,7 +195,7 @@ static int fc2580_set_params(struct dvb_ + + f_ref = 2UL * priv->cfg->clock / r_val; + n_val = div_u64_rem(f_vco, f_ref, &k_val); +- k_val_reg = 1UL * k_val * (1 << 20) / f_ref; ++ k_val_reg = div_u64(1ULL * k_val * (1 << 20), f_ref); + + ret = fc2580_wr_reg(priv, 0x18, r18_val | ((k_val_reg >> 16) & 0xff)); + if (ret < 0) +@@ -348,8 +348,8 @@ static int fc2580_set_params(struct dvb_ + if (ret < 0) + goto err; + +- ret = fc2580_wr_reg(priv, 0x37, 1UL * priv->cfg->clock * \ +- fc2580_if_filter_lut[i].mul / 1000000000); ++ ret = fc2580_wr_reg(priv, 0x37, div_u64(1ULL * priv->cfg->clock * ++ fc2580_if_filter_lut[i].mul, 1000000000)); + if (ret < 0) + goto err; + +--- a/drivers/media/tuners/fc2580_priv.h ++++ b/drivers/media/tuners/fc2580_priv.h +@@ -22,6 +22,7 @@ + #define FC2580_PRIV_H + + #include "fc2580.h" ++#include + + struct fc2580_reg_val { + u8 reg; diff --git a/queue-3.14/powerpc-fix-64-bit-builds-with-binutils-2.24.patch b/queue-3.14/powerpc-fix-64-bit-builds-with-binutils-2.24.patch new file mode 100644 index 00000000000..2f1e259f6a6 --- /dev/null +++ b/queue-3.14/powerpc-fix-64-bit-builds-with-binutils-2.24.patch @@ -0,0 +1,80 @@ +From 7998eb3dc700aaf499f93f50b3d77da834ef9e1d Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Thu, 15 May 2014 09:33:42 -0700 +Subject: powerpc: Fix 64 bit builds with binutils 2.24 + +From: Guenter Roeck + +commit 7998eb3dc700aaf499f93f50b3d77da834ef9e1d upstream. + +With binutils 2.24, various 64 bit builds fail with relocation errors +such as + +arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': + (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI + against symbol `interrupt_base_book3e' defined in .text section + in arch/powerpc/kernel/built-in.o +arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': + (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI + against symbol `interrupt_end_book3e' defined in .text section + in arch/powerpc/kernel/built-in.o + +The assembler maintainer says: + + I changed the ABI, something that had to be done but unfortunately + happens to break the booke kernel code. When building up a 64-bit + value with lis, ori, shl, oris, ori or similar sequences, you now + should use @high and @higha in place of @h and @ha. @h and @ha + (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) + now report overflow if the value is out of 32-bit signed range. + ie. @h and @ha assume you're building a 32-bit value. This is needed + to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h + and @toc@ha expressions, and for consistency I did the same for all + other @h and @ha relocs. + +Replacing @h with @high in one strategic location fixes the relocation +errors. This has to be done conditionally since the assembler either +supports @h or @high but not both. + +Signed-off-by: Guenter Roeck +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/Makefile | 4 +++- + arch/powerpc/include/asm/ppc_asm.h | 7 ++++++- + 2 files changed, 9 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/Makefile ++++ b/arch/powerpc/Makefile +@@ -149,7 +149,9 @@ endif + + CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell) + +-KBUILD_CPPFLAGS += -Iarch/$(ARCH) ++asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) ++ ++KBUILD_CPPFLAGS += -Iarch/$(ARCH) $(asinstr) + KBUILD_AFLAGS += -Iarch/$(ARCH) + KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y) + CPP = $(CC) -E $(KBUILD_CFLAGS) +--- a/arch/powerpc/include/asm/ppc_asm.h ++++ b/arch/powerpc/include/asm/ppc_asm.h +@@ -318,11 +318,16 @@ n: + addi reg,reg,(name - 0b)@l; + + #ifdef __powerpc64__ ++#ifdef HAVE_AS_ATHIGH ++#define __AS_ATHIGH high ++#else ++#define __AS_ATHIGH h ++#endif + #define LOAD_REG_IMMEDIATE(reg,expr) \ + lis reg,(expr)@highest; \ + ori reg,reg,(expr)@higher; \ + rldicr reg,reg,32,31; \ +- oris reg,reg,(expr)@h; \ ++ oris reg,reg,(expr)@__AS_ATHIGH; \ + ori reg,reg,(expr)@l; + + #define LOAD_REG_ADDR(reg,name) \ diff --git a/queue-3.14/powerpc-irq-work-racing-with-timer-interrupt-can-result-in-timer-interrupt-hang.patch b/queue-3.14/powerpc-irq-work-racing-with-timer-interrupt-can-result-in-timer-interrupt-hang.patch new file mode 100644 index 00000000000..35bca4b9fe4 --- /dev/null +++ b/queue-3.14/powerpc-irq-work-racing-with-timer-interrupt-can-result-in-timer-interrupt-hang.patch @@ -0,0 +1,70 @@ +From 8050936caf125fbe54111ba5e696b68a360556ba Mon Sep 17 00:00:00 2001 +From: Anton Blanchard +Date: Fri, 9 May 2014 17:47:12 +1000 +Subject: powerpc: irq work racing with timer interrupt can result in timer interrupt hang + +From: Anton Blanchard + +commit 8050936caf125fbe54111ba5e696b68a360556ba upstream. + +I am seeing an issue where a CPU running perf eventually hangs. +Traces show timer interrupts happening every 4 seconds even +when a userspace task is running on the CPU. /proc/timer_list +also shows pending hrtimers have not run in over an hour, +including the scheduler. + +Looking closer, decrementers_next_tb is getting set to +0xffffffffffffffff, and at that point we will never take +a timer interrupt again. + +In __timer_interrupt() we set decrementers_next_tb to +0xffffffffffffffff and rely on ->event_handler to update it: + + *next_tb = ~(u64)0; + if (evt->event_handler) + evt->event_handler(evt); + +In this case ->event_handler is hrtimer_interrupt. This will eventually +call back through the clockevents code with the next event to be +programmed: + +static int decrementer_set_next_event(unsigned long evt, + struct clock_event_device *dev) +{ + /* Don't adjust the decrementer if some irq work is pending */ + if (test_irq_work_pending()) + return 0; + __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt; + +If irq work came in between these two points, we will return +before updating decrementers_next_tb and we never process a timer +interrupt again. + +This looks to have been introduced by 0215f7d8c53f (powerpc: Fix races +with irq_work). Fix it by removing the early exit and relying on +code later on in the function to force an early decrementer: + + /* We may have raced with new irq work */ + if (test_irq_work_pending()) + set_dec(1); + +Signed-off-by: Anton Blanchard +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/time.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/arch/powerpc/kernel/time.c ++++ b/arch/powerpc/kernel/time.c +@@ -805,9 +805,6 @@ static void __init clocksource_init(void + static int decrementer_set_next_event(unsigned long evt, + struct clock_event_device *dev) + { +- /* Don't adjust the decrementer if some irq work is pending */ +- if (test_irq_work_pending()) +- return 0; + __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt; + set_dec(evt); + diff --git a/queue-3.14/powerpc-kexec-fix-processor-x-is-stuck-issue-during-kexec-from-st-mode.patch b/queue-3.14/powerpc-kexec-fix-processor-x-is-stuck-issue-during-kexec-from-st-mode.patch new file mode 100644 index 00000000000..fa3467dcc36 --- /dev/null +++ b/queue-3.14/powerpc-kexec-fix-processor-x-is-stuck-issue-during-kexec-from-st-mode.patch @@ -0,0 +1,112 @@ +From 011e4b02f1da156ac7fea28a9da878f3c23af739 Mon Sep 17 00:00:00 2001 +From: "Srivatsa S. Bhat" +Date: Tue, 27 May 2014 16:25:34 +0530 +Subject: powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode + +From: "Srivatsa S. Bhat" + +commit 011e4b02f1da156ac7fea28a9da878f3c23af739 upstream. + +If we try to perform a kexec when the machine is in ST (Single-Threaded) mode +(ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we +get the following messages during boot: + +[ 0.089866] POWER8 performance monitor hardware support registered +[ 0.089985] power8-pmu: PMAO restore workaround active. +[ 5.095419] Processor 1 is stuck. +[ 10.097933] Processor 2 is stuck. +[ 15.100480] Processor 3 is stuck. +[ 20.102982] Processor 4 is stuck. +[ 25.105489] Processor 5 is stuck. +[ 30.108005] Processor 6 is stuck. +[ 35.110518] Processor 7 is stuck. +[ 40.113369] Processor 9 is stuck. +[ 45.115879] Processor 10 is stuck. +[ 50.118389] Processor 11 is stuck. +[ 55.120904] Processor 12 is stuck. +[ 60.123425] Processor 13 is stuck. +[ 65.125970] Processor 14 is stuck. +[ 70.128495] Processor 15 is stuck. +[ 75.131316] Processor 17 is stuck. + +Note that only the sibling threads are stuck, while the primary threads (0, 8, +16 etc) boot just fine. Looking closer at the previous step of kexec, we observe +that kexec tries to wakeup (bring online) the sibling threads of all the cores, +before performing kexec: + +[ 9464.131231] Starting new kernel +[ 9464.148507] kexec: Waking offline cpu 1. +[ 9464.148552] kexec: Waking offline cpu 2. +[ 9464.148600] kexec: Waking offline cpu 3. +[ 9464.148636] kexec: Waking offline cpu 4. +[ 9464.148671] kexec: Waking offline cpu 5. +[ 9464.148708] kexec: Waking offline cpu 6. +[ 9464.148743] kexec: Waking offline cpu 7. +[ 9464.148779] kexec: Waking offline cpu 9. +[ 9464.148815] kexec: Waking offline cpu 10. +[ 9464.148851] kexec: Waking offline cpu 11. +[ 9464.148887] kexec: Waking offline cpu 12. +[ 9464.148922] kexec: Waking offline cpu 13. +[ 9464.148958] kexec: Waking offline cpu 14. +[ 9464.148994] kexec: Waking offline cpu 15. +[ 9464.149030] kexec: Waking offline cpu 17. + +Instrumenting this piece of code revealed that the cpu_up() operation actually +fails with -EBUSY. Thus, only the primary threads of all the cores are online +during kexec, and hence this is a sure-shot receipe for disaster, as explained +in commit e8e5c2155b (powerpc/kexec: Fix orphaned offline CPUs across kexec), +as well as in the comment above wake_offline_cpus(). + +It turns out that cpu_up() was returning -EBUSY because the variable +'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done +by migrate_to_reboot_cpu() inside kernel_kexec(). + +Now, migrate_to_reboot_cpu() was originally written with the assumption that +any further code will not need to perform CPU hotplug, since we are anyway in +the reboot path. However, kexec is clearly not such a case, since we depend on +onlining CPUs, atleast on powerpc. + +So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the +kexec path, to fix this regression in kexec on powerpc. + +Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we +can catch such issues more easily in the future. + +Fixes: c97102ba963 (kexec: migrate to reboot cpu) +Signed-off-by: Srivatsa S. Bhat +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/machine_kexec_64.c | 2 +- + kernel/kexec.c | 8 ++++++++ + 2 files changed, 9 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/machine_kexec_64.c ++++ b/arch/powerpc/kernel/machine_kexec_64.c +@@ -237,7 +237,7 @@ static void wake_offline_cpus(void) + if (!cpu_online(cpu)) { + printk(KERN_INFO "kexec: Waking offline cpu %d.\n", + cpu); +- cpu_up(cpu); ++ WARN_ON(cpu_up(cpu)); + } + } + } +--- a/kernel/kexec.c ++++ b/kernel/kexec.c +@@ -1682,6 +1682,14 @@ int kernel_kexec(void) + kexec_in_progress = true; + kernel_restart_prepare(NULL); + migrate_to_reboot_cpu(); ++ ++ /* ++ * migrate_to_reboot_cpu() disables CPU hotplug assuming that ++ * no further code needs to use CPU hotplug (which is true in ++ * the reboot case). However, the kexec path depends on using ++ * CPU hotplug again; so re-enable it here. ++ */ ++ cpu_hotplug_enable(); + printk(KERN_EMERG "Starting new kernel\n"); + machine_shutdown(); + } diff --git a/queue-3.14/powerpc-powernv-reset-root-port-in-firmware.patch b/queue-3.14/powerpc-powernv-reset-root-port-in-firmware.patch new file mode 100644 index 00000000000..bd716c370ed --- /dev/null +++ b/queue-3.14/powerpc-powernv-reset-root-port-in-firmware.patch @@ -0,0 +1,34 @@ +From 372cf1244d7c271806b83b32b09a1c8b1b31b353 Mon Sep 17 00:00:00 2001 +From: Gavin Shan +Date: Thu, 24 Apr 2014 18:00:22 +1000 +Subject: powerpc/powernv: Reset root port in firmware + +From: Gavin Shan + +commit 372cf1244d7c271806b83b32b09a1c8b1b31b353 upstream. + +Resetting root port has more stuff to do than that for PCIe switch +ports and we should have resetting root port done in firmware instead +of the kernel itself. The problem was introduced by commit 5b2e198e +("powerpc/powernv: Rework EEH reset"). + +Signed-off-by: Gavin Shan +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/platforms/powernv/eeh-ioda.c ++++ b/arch/powerpc/platforms/powernv/eeh-ioda.c +@@ -549,7 +549,8 @@ static int ioda_eeh_reset(struct eeh_pe + ret = ioda_eeh_phb_reset(hose, option); + } else { + bus = eeh_pe_bus_get(pe); +- if (pci_is_root_bus(bus)) ++ if (pci_is_root_bus(bus) || ++ pci_is_root_bus(bus->parent)) + ret = ioda_eeh_root_reset(hose, option); + else + ret = ioda_eeh_bridge_reset(hose, bus->self, option); diff --git a/queue-3.14/series b/queue-3.14/series index 71bd235edb6..51b43481d2a 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -207,3 +207,17 @@ acpi-video-revert-native-brightness-quirk-for-thinkpad-t530.patch i2c-rcar-bail-out-on-zero-length-transfers.patch i2c-designware-mask-all-interrupts-during-i2c-controller-enable.patch i2c-s3c2410-resume-race-fix.patch +intel_pstate-set-turbo-vid-for-baytrail.patch +intel_pstate-remove-setting-p-state-to-max-on-init.patch +crypto-caam-add-allocation-failure-handling-in-sprintfcat-macro.patch +crypto-s390-fix-aes-des-ctr-mode-concurrency-finding.patch +clk-fix-double-free-due-to-devm_clk_register.patch +clk-fix-slab-corruption-in-clk_unregister.patch +powerpc-powernv-reset-root-port-in-firmware.patch +powerpc-irq-work-racing-with-timer-interrupt-can-result-in-timer-interrupt-hang.patch +powerpc-fix-64-bit-builds-with-binutils-2.24.patch +powerpc-kexec-fix-processor-x-is-stuck-issue-during-kexec-from-st-mode.patch +spi-core-ignore-unsupported-dual-quad-transfer-mode-bits.patch +libceph-fix-corruption-when-using-page_count-0-page-in-rbd.patch +iommu-amd-fix-interrupt-remapping-for-aliased-devices.patch +media-fc2580-fix-tuning-failure-on-32-bit-arch.patch diff --git a/queue-3.14/spi-core-ignore-unsupported-dual-quad-transfer-mode-bits.patch b/queue-3.14/spi-core-ignore-unsupported-dual-quad-transfer-mode-bits.patch new file mode 100644 index 00000000000..7881742a0c2 --- /dev/null +++ b/queue-3.14/spi-core-ignore-unsupported-dual-quad-transfer-mode-bits.patch @@ -0,0 +1,56 @@ +From 83596fbeb5d28e8cb8878786133945d4dc7c0090 Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Mon, 14 Apr 2014 19:39:53 +0200 +Subject: spi: core: Ignore unsupported Dual/Quad Transfer Mode bits + +From: Geert Uytterhoeven + +commit 83596fbeb5d28e8cb8878786133945d4dc7c0090 upstream. + +The availability of SPI Dual or Quad Transfer Mode as indicated by the +"spi-tx-bus-width" and "spi-rx-bus-width" properties in the device tree is +a hardware property of the SPI master, SPI slave, and board wiring. Hence +the SPI core should not reject an SPI slave because an SPI master driver +doesn't (yet) support Dual or Quad Transfer Mode. + +Change the lack of Dual or Quad Transfer Mode support in the SPI master +driver from an error condition to a warning condition, and ignore the +unsupported mode bits, falling back to Single Transfer Mode, to avoid +breakages when running old kernels with new device trees. + +Fixes: f477b7fb13df (spi: DUAL and QUAD support) +Signed-off-by: Geert Uytterhoeven +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/spi/spi.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/drivers/spi/spi.c ++++ b/drivers/spi/spi.c +@@ -1568,7 +1568,7 @@ EXPORT_SYMBOL_GPL(spi_busnum_to_master); + */ + int spi_setup(struct spi_device *spi) + { +- unsigned bad_bits; ++ unsigned bad_bits, ugly_bits; + int status = 0; + + /* check mode to prevent that DUAL and QUAD set at the same time +@@ -1588,6 +1588,15 @@ int spi_setup(struct spi_device *spi) + * that aren't supported with their current master + */ + bad_bits = spi->mode & ~spi->master->mode_bits; ++ ugly_bits = bad_bits & ++ (SPI_TX_DUAL | SPI_TX_QUAD | SPI_RX_DUAL | SPI_RX_QUAD); ++ if (ugly_bits) { ++ dev_warn(&spi->dev, ++ "setup: ignoring unsupported mode bits %x\n", ++ ugly_bits); ++ spi->mode &= ~ugly_bits; ++ bad_bits &= ~ugly_bits; ++ } + if (bad_bits) { + dev_err(&spi->dev, "setup: unsupported mode bits %x\n", + bad_bits);