From: Greg Kroah-Hartman Date: Mon, 6 Oct 2014 00:04:59 +0000 (-0700) Subject: 3.16-stable patches X-Git-Tag: v3.10.57~27 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cf3f186bc5c318646bba772628f6a46dead0b68f;p=thirdparty%2Fkernel%2Fstable-queue.git 3.16-stable patches added patches: acpi-i915-update-the-condition-to-ignore-firmware-backlight-change-request.patch asoc-core-fix-possible-zero_size_ptr-pointer-dereferencing-error.patch asoc-ssm2602-do-not-hardcode-type-to-ssm2602.patch cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch cpufreq-pcc-cpufreq-fix-wait_event-under-spinlock.patch drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch fix-problem-recognizing-symlinks.patch i2c-qup-fix-order-of-runtime-pm-initialization.patch i2c-rk3x-fix-0-length-write-transfers.patch init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch md-raid5-disable-discard-by-default-due-to-safety-concerns.patch mm-memcontrol-do-not-iterate-uninitialized-memcgs.patch mm-migrate-close-race-between-migration-completion-and-mprotect.patch perf-fix-perf-bug-in-fork.patch ring-buffer-fix-infinite-spin-in-reading-buffer.patch uas-log-a-warning-when-we-cannot-use-uas-because-the-hcd-lacks-streams.patch uas-only-complain-about-missing-sg-if-all-other-checks-succeed.patch --- diff --git a/queue-3.16/acpi-i915-update-the-condition-to-ignore-firmware-backlight-change-request.patch b/queue-3.16/acpi-i915-update-the-condition-to-ignore-firmware-backlight-change-request.patch new file mode 100644 index 00000000000..d0d2196e09e --- /dev/null +++ b/queue-3.16/acpi-i915-update-the-condition-to-ignore-firmware-backlight-change-request.patch @@ -0,0 +1,68 @@ +From 77076c7aac0184cae2d8a358cf6e6ed1f195fe3f Mon Sep 17 00:00:00 2001 +From: Aaron Lu +Date: Fri, 26 Sep 2014 10:30:08 +0800 +Subject: ACPI / i915: Update the condition to ignore firmware backlight change request +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Aaron Lu + +commit 77076c7aac0184cae2d8a358cf6e6ed1f195fe3f upstream. + +Some of the Thinkpads' firmware will issue a backlight change request +through i915 operation region unconditionally on AC plug/unplug, the +backlight level used is arbitrary and thus should be ignored. This is +handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests +for backlight change). Then there is a Dell laptop whose vendor backlight +interface also makes use of operation region to change backlight level +and with the above commit, that interface no long works. The condition +used to ignore the backlight change request from firmware is thus +changed to: if the vendor backlight interface is not in use and the ACPI +backlight interface is broken, we ignore the requests; oterwise, we keep +processing them. + +Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) +Link: https://lkml.org/lkml/2014/9/23/854 +Reported-and-tested-by: Pali Rohár +Signed-off-by: Aaron Lu +Acked-by: Daniel Vetter +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_opregion.c | 16 +++++++++++----- + 1 file changed, 11 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_opregion.c ++++ b/drivers/gpu/drm/i915/intel_opregion.c +@@ -395,6 +395,16 @@ int intel_opregion_notify_adapter(struct + return -EINVAL; + } + ++/* ++ * If the vendor backlight interface is not in use and ACPI backlight interface ++ * is broken, do not bother processing backlight change requests from firmware. ++ */ ++static bool should_ignore_backlight_request(void) ++{ ++ return acpi_video_backlight_support() && ++ !acpi_video_verify_backlight_support(); ++} ++ + static u32 asle_set_backlight(struct drm_device *dev, u32 bclp) + { + struct drm_i915_private *dev_priv = dev->dev_private; +@@ -403,11 +413,7 @@ static u32 asle_set_backlight(struct drm + + DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp); + +- /* +- * If the acpi_video interface is not supposed to be used, don't +- * bother processing backlight level change requests from firmware. +- */ +- if (!acpi_video_verify_backlight_support()) { ++ if (should_ignore_backlight_request()) { + DRM_DEBUG_KMS("opregion backlight request ignored\n"); + return 0; + } diff --git a/queue-3.16/asoc-core-fix-possible-zero_size_ptr-pointer-dereferencing-error.patch b/queue-3.16/asoc-core-fix-possible-zero_size_ptr-pointer-dereferencing-error.patch new file mode 100644 index 00000000000..cc3cd5e6656 --- /dev/null +++ b/queue-3.16/asoc-core-fix-possible-zero_size_ptr-pointer-dereferencing-error.patch @@ -0,0 +1,35 @@ +From 6596aa047b624aeec2ea321962cfdecf9953a383 Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Sun, 28 Sep 2014 17:29:37 +0800 +Subject: ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error. + +From: Xiubo Li + +commit 6596aa047b624aeec2ea321962cfdecf9953a383 upstream. + +Since we cannot make sure the 'params->num_regs' will always be none +zero here, and then if it equals to zero, the kmemdup() will return +ZERO_SIZE_PTR, which equals to ((void *)16). + +So this patch fix this with just doing the zero check before calling +kmemdup(). + +Signed-off-by: Xiubo Li +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/soc-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/soc-core.c ++++ b/sound/soc/soc-core.c +@@ -3181,7 +3181,7 @@ int snd_soc_bytes_put(struct snd_kcontro + unsigned int val, mask; + void *data; + +- if (!component->regmap) ++ if (!component->regmap || !params->num_regs) + return -EINVAL; + + len = params->num_regs * component->val_bytes; diff --git a/queue-3.16/asoc-ssm2602-do-not-hardcode-type-to-ssm2602.patch b/queue-3.16/asoc-ssm2602-do-not-hardcode-type-to-ssm2602.patch new file mode 100644 index 00000000000..6be16cbace5 --- /dev/null +++ b/queue-3.16/asoc-ssm2602-do-not-hardcode-type-to-ssm2602.patch @@ -0,0 +1,35 @@ +From fe2a08b3bf1a6e35c00e18843bc19aa1778432c3 Mon Sep 17 00:00:00 2001 +From: Stefan Kristiansson +Date: Mon, 29 Sep 2014 22:39:13 +0300 +Subject: ASoC: ssm2602: do not hardcode type to SSM2602 + +From: Stefan Kristiansson + +commit fe2a08b3bf1a6e35c00e18843bc19aa1778432c3 upstream. + +The correct type (SSM2602/SSM2603/SSM2604) is passed down +from the ssm2602_spi_probe()/ssm2602_spi_probe() functions, +so use that instead of hardcoding it to SSM2602 in +ssm2602_probe(). + +Fixes: c924dc68f737 ("ASoC: ssm2602: Split SPI and I2C code into different modules") +Signed-off-by: Stefan Kristiansson +Signed-off-by: Mark Brown +Acked-by: Lars-Peter Clausen +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/codecs/ssm2602.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/codecs/ssm2602.c ++++ b/sound/soc/codecs/ssm2602.c +@@ -647,7 +647,7 @@ int ssm2602_probe(struct device *dev, en + return -ENOMEM; + + dev_set_drvdata(dev, ssm2602); +- ssm2602->type = SSM2602; ++ ssm2602->type = type; + ssm2602->regmap = regmap; + + return snd_soc_register_codec(dev, &soc_codec_dev_ssm2602, diff --git a/queue-3.16/cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch b/queue-3.16/cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch new file mode 100644 index 00000000000..dfef28e5c59 --- /dev/null +++ b/queue-3.16/cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch @@ -0,0 +1,41 @@ +From d62dbf77f7dfaa6fb455b4b9828069a11965929c Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 26 Sep 2014 22:19:12 +0200 +Subject: cpufreq: integrator: fix integrator_cpufreq_remove return type + +From: Arnd Bergmann + +commit d62dbf77f7dfaa6fb455b4b9828069a11965929c upstream. + +When building this driver as a module, we get a helpful warning +about the return type: + +drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type + .remove = __exit_p(integrator_cpufreq_remove), + +If the remove callback returns void, the caller gets an undefined +value as it expects an integer to be returned. This fixes the +problem by passing down the value from cpufreq_unregister_driver. + +Signed-off-by: Arnd Bergmann +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/integrator-cpufreq.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/cpufreq/integrator-cpufreq.c ++++ b/drivers/cpufreq/integrator-cpufreq.c +@@ -213,9 +213,9 @@ static int __init integrator_cpufreq_pro + return cpufreq_register_driver(&integrator_driver); + } + +-static void __exit integrator_cpufreq_remove(struct platform_device *pdev) ++static int __exit integrator_cpufreq_remove(struct platform_device *pdev) + { +- cpufreq_unregister_driver(&integrator_driver); ++ return cpufreq_unregister_driver(&integrator_driver); + } + + static const struct of_device_id integrator_cpufreq_match[] = { diff --git a/queue-3.16/cpufreq-pcc-cpufreq-fix-wait_event-under-spinlock.patch b/queue-3.16/cpufreq-pcc-cpufreq-fix-wait_event-under-spinlock.patch new file mode 100644 index 00000000000..4d544a820c0 --- /dev/null +++ b/queue-3.16/cpufreq-pcc-cpufreq-fix-wait_event-under-spinlock.patch @@ -0,0 +1,84 @@ +From e65b5ddba84634f31d42dfd86013f4c6be5e9e32 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Sat, 27 Sep 2014 21:56:08 +0200 +Subject: cpufreq: pcc-cpufreq: Fix wait_event() under spinlock + +From: "Rafael J. Wysocki" + +commit e65b5ddba84634f31d42dfd86013f4c6be5e9e32 upstream. + +Fix the following bug introduced by commit 8fec051eea73 (cpufreq: +Convert existing drivers to use cpufreq_freq_transition_{begin|end}) +that forgot to move the spin_lock() in pcc_cpufreq_target() past +cpufreq_freq_transition_begin() which calls wait_event(): + +BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370 +in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe +Preemption disabled at:[] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq] +[ 51.025044] +CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7 +Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 + 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000 + ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090 + 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00 +Call Trace: + [] dump_stack+0x4d/0x90 + [] ___might_sleep+0x10f/0x180 + [] __might_sleep+0x48/0xd0 + [] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing); + [] ? preempt_count_add+0xb9/0xc0 + [] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock); + [] ? update_ts_time_stats+0x7f/0xb0 + [] __cpufreq_driver_target+0x85/0x170 + [] od_check_cpu+0xa8/0xb0 + [] dbs_check_cpu+0x180/0x1d0 + [] cpufreq_governor_dbs+0x3b0/0x720 + [] od_cpufreq_governor_dbs+0x33/0xe0 + [] __cpufreq_governor+0xa9/0x210 + [] cpufreq_set_policy+0x1e2/0x2e0 + [] cpufreq_init_policy+0x8c/0x110 + [] ? cpufreq_update_policy+0x1b0/0x1b0 + [] ? preempt_count_sub+0xb9/0x100 + [] __cpufreq_add_dev+0x596/0x6b0 + [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] + [] cpufreq_add_dev+0xe/0x10 + [] subsys_interface_register+0xc1/0xf0 + [] ? preempt_count_sub+0xb9/0x100 + [] cpufreq_register_driver+0x117/0x2a0 + [] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq] + [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] + [] do_one_initcall+0xc8/0x1f0 + [] ? __vunmap+0x9d/0x100 + [] do_init_module+0x30/0x1b0 + [] load_module+0x686/0x710 + [] ? do_init_module+0x1b0/0x1b0 + [] SyS_init_module+0x9b/0xc0 + [] system_call_fastpath+0x16/0x1b + +Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) +Reported-and-tested-by: Mike Galbraith +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/pcc-cpufreq.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/cpufreq/pcc-cpufreq.c ++++ b/drivers/cpufreq/pcc-cpufreq.c +@@ -204,7 +204,6 @@ static int pcc_cpufreq_target(struct cpu + u32 input_buffer; + int cpu; + +- spin_lock(&pcc_lock); + cpu = policy->cpu; + pcc_cpu_data = per_cpu_ptr(pcc_cpu_info, cpu); + +@@ -216,6 +215,7 @@ static int pcc_cpufreq_target(struct cpu + freqs.old = policy->cur; + freqs.new = target_freq; + cpufreq_freq_transition_begin(policy, &freqs); ++ spin_lock(&pcc_lock); + + input_buffer = 0x1 | (((target_freq * 100) + / (ioread32(&pcch_hdr->nominal) * 1000)) << 8); diff --git a/queue-3.16/drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch b/queue-3.16/drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch new file mode 100644 index 00000000000..dff30a533c4 --- /dev/null +++ b/queue-3.16/drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch @@ -0,0 +1,84 @@ +From 91e56499304f3d612053a9cf17f350868182c7d8 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Thu, 25 Sep 2014 10:13:12 +0100 +Subject: drm/i915: Flush the PTEs after updating them before suspend + +From: Chris Wilson + +commit 91e56499304f3d612053a9cf17f350868182c7d8 upstream. + +As we use WC updates of the PTE, we are responsible for notifying the +hardware when to flush its TLBs. Do so after we zap all the PTEs before +suspend (and the BIOS tries to read our GTT). + +Fixes a regression from + +commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 +Author: Ben Widawsky +Date: Wed Oct 16 09:21:30 2013 -0700 + + drm/i915: Disable GGTT PTEs on GEN6+ suspend + +that survived and continue to cause harm even after + +commit e568af1c626031925465a5caaab7cca1303d55c7 +Author: Daniel Vetter +Date: Wed Mar 26 20:08:20 2014 +0100 + + drm/i915: Undo gtt scratch pte unmapping again + +v2: Trivial rebase. +v3: Fixes requires pointer dances. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340 +Tested-by: ming.yao@intel.com +Signed-off-by: Chris Wilson +Cc: Takashi Iwai +Cc: Paulo Zanoni +Cc: Todd Previte +Cc: Daniel Vetter +Reviewed-by: Daniel Vetter +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/i915_gem_gtt.c ++++ b/drivers/gpu/drm/i915/i915_gem_gtt.c +@@ -1297,6 +1297,16 @@ void i915_check_and_clear_faults(struct + POSTING_READ(RING_FAULT_REG(&dev_priv->ring[RCS])); + } + ++static void i915_ggtt_flush(struct drm_i915_private *dev_priv) ++{ ++ if (INTEL_INFO(dev_priv->dev)->gen < 6) { ++ intel_gtt_chipset_flush(); ++ } else { ++ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN); ++ POSTING_READ(GFX_FLSH_CNTL_GEN6); ++ } ++} ++ + void i915_gem_suspend_gtt_mappings(struct drm_device *dev) + { + struct drm_i915_private *dev_priv = dev->dev_private; +@@ -1313,6 +1323,8 @@ void i915_gem_suspend_gtt_mappings(struc + dev_priv->gtt.base.start, + dev_priv->gtt.base.total, + true); ++ ++ i915_ggtt_flush(dev_priv); + } + + void i915_gem_restore_gtt_mappings(struct drm_device *dev) +@@ -1365,7 +1377,7 @@ void i915_gem_restore_gtt_mappings(struc + gen6_write_pdes(container_of(vm, struct i915_hw_ppgtt, base)); + } + +- i915_gem_chipset_flush(dev); ++ i915_ggtt_flush(dev_priv); + } + + int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj) diff --git a/queue-3.16/fix-problem-recognizing-symlinks.patch b/queue-3.16/fix-problem-recognizing-symlinks.patch new file mode 100644 index 00000000000..b9dbe92a5d8 --- /dev/null +++ b/queue-3.16/fix-problem-recognizing-symlinks.patch @@ -0,0 +1,49 @@ +From 19e81573fca7b87ced7701e01ba164b968d929bd Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Thu, 25 Sep 2014 01:26:55 -0500 +Subject: Fix problem recognizing symlinks + +From: Steve French + +commit 19e81573fca7b87ced7701e01ba164b968d929bd upstream. + +Changeset eb85d94bd introduced a problem where if a cifs open +fails during query info of a file we +will still try to close the file (happens with certain types +of reparse points) even though the file handle is not valid. + +In addition for SMB2/SMB3 we were not mapping the return code returned +by Windows when trying to open a file (like a Windows NFS symlink) +which is a reparse point. + +Signed-off-by: Steve French +Reviewed-by: Pavel Shilovsky +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/smb1ops.c | 2 +- + fs/cifs/smb2maperror.c | 2 ++ + 2 files changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/cifs/smb1ops.c ++++ b/fs/cifs/smb1ops.c +@@ -586,7 +586,7 @@ cifs_query_path_info(const unsigned int + tmprc = CIFS_open(xid, &oparms, &oplock, NULL); + if (tmprc == -EOPNOTSUPP) + *symlink = true; +- else ++ else if (tmprc == 0) + CIFSSMBClose(xid, tcon, fid.netfid); + } + +--- a/fs/cifs/smb2maperror.c ++++ b/fs/cifs/smb2maperror.c +@@ -256,6 +256,8 @@ static const struct status_to_posix_erro + {STATUS_DLL_MIGHT_BE_INCOMPATIBLE, -EIO, + "STATUS_DLL_MIGHT_BE_INCOMPATIBLE"}, + {STATUS_STOPPED_ON_SYMLINK, -EOPNOTSUPP, "STATUS_STOPPED_ON_SYMLINK"}, ++ {STATUS_IO_REPARSE_TAG_NOT_HANDLED, -EOPNOTSUPP, ++ "STATUS_REPARSE_NOT_HANDLED"}, + {STATUS_DEVICE_REQUIRES_CLEANING, -EIO, + "STATUS_DEVICE_REQUIRES_CLEANING"}, + {STATUS_DEVICE_DOOR_OPEN, -EIO, "STATUS_DEVICE_DOOR_OPEN"}, diff --git a/queue-3.16/i2c-qup-fix-order-of-runtime-pm-initialization.patch b/queue-3.16/i2c-qup-fix-order-of-runtime-pm-initialization.patch new file mode 100644 index 00000000000..df7ec8a00c4 --- /dev/null +++ b/queue-3.16/i2c-qup-fix-order-of-runtime-pm-initialization.patch @@ -0,0 +1,50 @@ +From 86b59bbfae2a895aa26b3d15f31b1a705dbfede1 Mon Sep 17 00:00:00 2001 +From: Andy Gross +Date: Mon, 29 Sep 2014 17:00:51 -0500 +Subject: i2c: qup: Fix order of runtime pm initialization + +From: Andy Gross + +commit 86b59bbfae2a895aa26b3d15f31b1a705dbfede1 upstream. + +The runtime pm calls need to be done before populating the children via the +i2c_add_adapter call. If this is not done, a child can run into issues trying +to do i2c read/writes due to the pm_runtime_sync failing. + +Signed-off-by: Andy Gross +Reviewed-by: Felipe Balbi +Acked-by: Bjorn Andersson +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-qup.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/drivers/i2c/busses/i2c-qup.c ++++ b/drivers/i2c/busses/i2c-qup.c +@@ -670,16 +670,20 @@ static int qup_i2c_probe(struct platform + qup->adap.dev.of_node = pdev->dev.of_node; + strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name)); + +- ret = i2c_add_adapter(&qup->adap); +- if (ret) +- goto fail; +- + pm_runtime_set_autosuspend_delay(qup->dev, MSEC_PER_SEC); + pm_runtime_use_autosuspend(qup->dev); + pm_runtime_set_active(qup->dev); + pm_runtime_enable(qup->dev); ++ ++ ret = i2c_add_adapter(&qup->adap); ++ if (ret) ++ goto fail_runtime; ++ + return 0; + ++fail_runtime: ++ pm_runtime_disable(qup->dev); ++ pm_runtime_set_suspended(qup->dev); + fail: + qup_i2c_disable_clocks(qup); + return ret; diff --git a/queue-3.16/i2c-rk3x-fix-0-length-write-transfers.patch b/queue-3.16/i2c-rk3x-fix-0-length-write-transfers.patch new file mode 100644 index 00000000000..39617c097ca --- /dev/null +++ b/queue-3.16/i2c-rk3x-fix-0-length-write-transfers.patch @@ -0,0 +1,36 @@ +From cf27020d2f253bac6457d6833b97141030f0122a Mon Sep 17 00:00:00 2001 +From: Alexandru M Stan +Date: Wed, 1 Oct 2014 10:40:41 -0700 +Subject: i2c: rk3x: fix 0 length write transfers + +From: Alexandru M Stan + +commit cf27020d2f253bac6457d6833b97141030f0122a upstream. + +i2cdetect -q was broken (everything was a false positive, and no transfers were +actually being sent over i2c). The way it works is by sending a 0 length write +request and checking for NACK. This patch fixes the 0 length writes and actually +sends them. + +Reported-by: Doug Anderson +Signed-off-by: Alexandru M Stan +Tested-by: Doug Anderson +Tested-by: Max Schwarz +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-rk3x.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i2c/busses/i2c-rk3x.c ++++ b/drivers/i2c/busses/i2c-rk3x.c +@@ -238,7 +238,7 @@ static void rk3x_i2c_fill_transmit_buf(s + for (i = 0; i < 8; ++i) { + val = 0; + for (j = 0; j < 4; ++j) { +- if (i2c->processed == i2c->msg->len) ++ if ((i2c->processed == i2c->msg->len) && (cnt != 0)) + break; + + if (i2c->processed == 0 && cnt == 0) diff --git a/queue-3.16/init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch b/queue-3.16/init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch new file mode 100644 index 00000000000..f027eab157b --- /dev/null +++ b/queue-3.16/init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch @@ -0,0 +1,41 @@ +From 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f Mon Sep 17 00:00:00 2001 +From: Josh Triplett +Date: Fri, 3 Oct 2014 16:19:24 -0700 +Subject: init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu + +From: Josh Triplett + +commit 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f upstream. + +commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow +architectures to skip futex_atomic_cmpxchg_inatomic() test") added the +HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in +the middle of the options for the EXPERT menu. However, +HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops +placing items in the EXPERT menu, and displays the remaining several +EXPERT items (starting with EPOLL) directly in the General Setup menu. + +Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make +HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the +subsequent items display as part of the EXPERT menu again; the EMBEDDED +menu now appears as the next top-level item in the General Setup menu, +which makes General Setup much shorter and more usable. + +Signed-off-by: Josh Triplett +Acked-by: Randy Dunlap +Signed-off-by: Greg Kroah-Hartman + +--- + init/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/init/Kconfig ++++ b/init/Kconfig +@@ -1432,6 +1432,7 @@ config FUTEX + + config HAVE_FUTEX_CMPXCHG + bool ++ depends on FUTEX + help + Architectures should select this if futex_atomic_cmpxchg_inatomic() + is implemented and always working. This removes a couple of runtime diff --git a/queue-3.16/md-raid5-disable-discard-by-default-due-to-safety-concerns.patch b/queue-3.16/md-raid5-disable-discard-by-default-due-to-safety-concerns.patch new file mode 100644 index 00000000000..397c31d1fbc --- /dev/null +++ b/queue-3.16/md-raid5-disable-discard-by-default-due-to-safety-concerns.patch @@ -0,0 +1,92 @@ +From 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Thu, 2 Oct 2014 13:45:00 +1000 +Subject: md/raid5: disable 'DISCARD' by default due to safety concerns. + +From: NeilBrown + +commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 upstream. + +It has come to my attention (thanks Martin) that 'discard_zeroes_data' +is only a hint. Some devices in some cases don't do what it +says on the label. + +The use of DISCARD in RAID5 depends on reads from discarded regions +being predictably zero. If a write to a previously discarded region +performs a read-modify-write cycle it assumes that the parity block +was consistent with the data blocks. If all were zero, this would +be the case. If some are and some aren't this would not be the case. +This could lead to data corruption after a device failure when +data needs to be reconstructed from the parity. + +As we cannot trust 'discard_zeroes_data', ignore it by default +and so disallow DISCARD on all raid4/5/6 arrays. + +As many devices are trustworthy, and as there are benefits to using +DISCARD, add a module parameter to over-ride this caution and cause +DISCARD to work if discard_zeroes_data is set. + +If a site want to enable DISCARD on some arrays but not on others they +should select DISCARD support at the filesystem level, and set the +raid456 module parameter. + raid456.devices_handle_discard_safely=Y + +As this is a data-safety issue, I believe this patch is suitable for +-stable. +DISCARD support for RAID456 was added in 3.7 + +Cc: Shaohua Li +Cc: "Martin K. Petersen" +Cc: Mike Snitzer +Cc: Heinz Mauelshagen +Acked-by: Martin K. Petersen +Acked-by: Mike Snitzer +Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637 +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -64,6 +64,10 @@ + #define cpu_to_group(cpu) cpu_to_node(cpu) + #define ANY_GROUP NUMA_NO_NODE + ++static bool devices_handle_discard_safely = false; ++module_param(devices_handle_discard_safely, bool, 0644); ++MODULE_PARM_DESC(devices_handle_discard_safely, ++ "Set to Y if all devices in each array reliably return zeroes on reads from discarded regions"); + static struct workqueue_struct *raid5_wq; + /* + * Stripe cache +@@ -6208,7 +6212,7 @@ static int run(struct mddev *mddev) + mddev->queue->limits.discard_granularity = stripe; + /* + * unaligned part of discard request will be ignored, so can't +- * guarantee discard_zerors_data ++ * guarantee discard_zeroes_data + */ + mddev->queue->limits.discard_zeroes_data = 0; + +@@ -6233,6 +6237,18 @@ static int run(struct mddev *mddev) + !bdev_get_queue(rdev->bdev)-> + limits.discard_zeroes_data) + discard_supported = false; ++ /* Unfortunately, discard_zeroes_data is not currently ++ * a guarantee - just a hint. So we only allow DISCARD ++ * if the sysadmin has confirmed that only safe devices ++ * are in use by setting a module parameter. ++ */ ++ if (!devices_handle_discard_safely) { ++ if (discard_supported) { ++ pr_info("md/raid456: discard support disabled due to uncertainty.\n"); ++ pr_info("Set raid456.devices_handle_discard_safely=Y to override.\n"); ++ } ++ discard_supported = false; ++ } + } + + if (discard_supported && diff --git a/queue-3.16/mm-memcontrol-do-not-iterate-uninitialized-memcgs.patch b/queue-3.16/mm-memcontrol-do-not-iterate-uninitialized-memcgs.patch new file mode 100644 index 00000000000..03cdd821849 --- /dev/null +++ b/queue-3.16/mm-memcontrol-do-not-iterate-uninitialized-memcgs.patch @@ -0,0 +1,103 @@ +From 2f7dd7a4100ad4affcb141605bef178ab98ccb18 Mon Sep 17 00:00:00 2001 +From: Johannes Weiner +Date: Thu, 2 Oct 2014 16:16:57 -0700 +Subject: mm: memcontrol: do not iterate uninitialized memcgs + +From: Johannes Weiner + +commit 2f7dd7a4100ad4affcb141605bef178ab98ccb18 upstream. + +The cgroup iterators yield css objects that have not yet gone through +css_online(), but they are not complete memcgs at this point and so the +memcg iterators should not return them. Commit d8ad30559715 ("mm/memcg: +iteration skip memcgs not yet fully initialized") set out to implement +exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does +not meet the ordering requirements for memcg, and so the iterator may +skip over initialized groups, or return partially initialized memcgs. + +The cgroup core can not reasonably provide a clear answer on whether the +object around the css has been fully initialized, as that depends on +controller-specific locking and lifetime rules. Thus, introduce a +memcg-specific flag that is set after the memcg has been initialized in +css_online(), and read before mem_cgroup_iter() callers access the memcg +members. + +Signed-off-by: Johannes Weiner +Cc: Tejun Heo +Acked-by: Michal Hocko +Cc: Hugh Dickins +Cc: Peter Zijlstra +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memcontrol.c | 36 +++++++++++++++++++++++++++++++----- + 1 file changed, 31 insertions(+), 5 deletions(-) + +--- a/mm/memcontrol.c ++++ b/mm/memcontrol.c +@@ -292,6 +292,9 @@ struct mem_cgroup { + /* vmpressure notifications */ + struct vmpressure vmpressure; + ++ /* css_online() has been completed */ ++ int initialized; ++ + /* + * the counter to account for mem+swap usage. + */ +@@ -1106,10 +1109,21 @@ skip_node: + * skipping css reference should be safe. + */ + if (next_css) { +- if ((next_css == &root->css) || +- ((next_css->flags & CSS_ONLINE) && +- css_tryget_online(next_css))) +- return mem_cgroup_from_css(next_css); ++ struct mem_cgroup *memcg = mem_cgroup_from_css(next_css); ++ ++ if (next_css == &root->css) ++ return memcg; ++ ++ if (css_tryget_online(next_css)) { ++ /* ++ * Make sure the memcg is initialized: ++ * mem_cgroup_css_online() orders the the ++ * initialization against setting the flag. ++ */ ++ if (smp_load_acquire(&memcg->initialized)) ++ return memcg; ++ css_put(next_css); ++ } + + prev_css = next_css; + goto skip_node; +@@ -6277,6 +6291,7 @@ mem_cgroup_css_online(struct cgroup_subs + { + struct mem_cgroup *memcg = mem_cgroup_from_css(css); + struct mem_cgroup *parent = mem_cgroup_from_css(css->parent); ++ int ret; + + if (css->id > MEM_CGROUP_ID_MAX) + return -ENOSPC; +@@ -6313,7 +6328,18 @@ mem_cgroup_css_online(struct cgroup_subs + } + mutex_unlock(&memcg_create_mutex); + +- return memcg_init_kmem(memcg, &memory_cgrp_subsys); ++ ret = memcg_init_kmem(memcg, &memory_cgrp_subsys); ++ if (ret) ++ return ret; ++ ++ /* ++ * Make sure the memcg is initialized: mem_cgroup_iter() ++ * orders reading memcg->initialized against its callers ++ * reading the memcg members. ++ */ ++ smp_store_release(&memcg->initialized, 1); ++ ++ return 0; + } + + /* diff --git a/queue-3.16/mm-migrate-close-race-between-migration-completion-and-mprotect.patch b/queue-3.16/mm-migrate-close-race-between-migration-completion-and-mprotect.patch new file mode 100644 index 00000000000..a8d37839007 --- /dev/null +++ b/queue-3.16/mm-migrate-close-race-between-migration-completion-and-mprotect.patch @@ -0,0 +1,44 @@ +From d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 Mon Sep 17 00:00:00 2001 +From: Mel Gorman +Date: Thu, 2 Oct 2014 19:47:41 +0100 +Subject: mm: migrate: Close race between migration completion and mprotect + +From: Mel Gorman + +commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream. + +A migration entry is marked as write if pte_write was true at the time the +entry was created. The VMA protections are not double checked when migration +entries are being removed as mprotect marks write-migration-entries as +read. It means that potentially we take a spurious fault to mark PTEs write +again but it's straight-forward. However, there is a race between write +migrations being marked read and migrations finishing. This potentially +allows a PTE to be write that should have been read. Close this race by +double checking the VMA permissions using maybe_mkwrite when migration +completes. + +[torvalds@linux-foundation.org: use maybe_mkwrite] +Signed-off-by: Mel Gorman +Acked-by: Rik van Riel +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/migrate.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/mm/migrate.c ++++ b/mm/migrate.c +@@ -146,8 +146,11 @@ static int remove_migration_pte(struct p + pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); + if (pte_swp_soft_dirty(*ptep)) + pte = pte_mksoft_dirty(pte); ++ ++ /* Recheck VMA as permissions can change since migration started */ + if (is_write_migration_entry(entry)) +- pte = pte_mkwrite(pte); ++ pte = maybe_mkwrite(pte, vma); ++ + #ifdef CONFIG_HUGETLB_PAGE + if (PageHuge(new)) { + pte = pte_mkhuge(pte); diff --git a/queue-3.16/perf-fix-perf-bug-in-fork.patch b/queue-3.16/perf-fix-perf-bug-in-fork.patch new file mode 100644 index 00000000000..bd52636dc5c --- /dev/null +++ b/queue-3.16/perf-fix-perf-bug-in-fork.patch @@ -0,0 +1,65 @@ +From 6c72e3501d0d62fc064d3680e5234f3463ec5a86 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Thu, 2 Oct 2014 16:17:02 -0700 +Subject: perf: fix perf bug in fork() + +From: Peter Zijlstra + +commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream. + +Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by +calling perf_event_free_task() when failing sched_fork() we will not yet +have done the memset() on ->perf_event_ctxp[] and will therefore try and +'free' the inherited contexts, which are still in use by the parent +process. This is bad.. + +Suggested-by: Oleg Nesterov +Reported-by: Oleg Nesterov +Reported-by: Sylvain 'ythier' Hitier +Signed-off-by: Peter Zijlstra (Intel) +Cc: Ingo Molnar +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/events/core.c | 4 +++- + kernel/fork.c | 5 +++-- + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -7921,8 +7921,10 @@ int perf_event_init_task(struct task_str + + for_each_task_context_nr(ctxn) { + ret = perf_event_init_context(child, ctxn); +- if (ret) ++ if (ret) { ++ perf_event_free_task(child); + return ret; ++ } + } + + return 0; +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -1326,7 +1326,7 @@ static struct task_struct *copy_process( + goto bad_fork_cleanup_policy; + retval = audit_alloc(p); + if (retval) +- goto bad_fork_cleanup_policy; ++ goto bad_fork_cleanup_perf; + /* copy all the process information */ + retval = copy_semundo(clone_flags, p); + if (retval) +@@ -1525,8 +1525,9 @@ bad_fork_cleanup_semundo: + exit_sem(p); + bad_fork_cleanup_audit: + audit_free(p); +-bad_fork_cleanup_policy: ++bad_fork_cleanup_perf: + perf_event_free_task(p); ++bad_fork_cleanup_policy: + #ifdef CONFIG_NUMA + mpol_put(p->mempolicy); + bad_fork_cleanup_threadgroup_lock: diff --git a/queue-3.16/ring-buffer-fix-infinite-spin-in-reading-buffer.patch b/queue-3.16/ring-buffer-fix-infinite-spin-in-reading-buffer.patch new file mode 100644 index 00000000000..3436f3b814d --- /dev/null +++ b/queue-3.16/ring-buffer-fix-infinite-spin-in-reading-buffer.patch @@ -0,0 +1,55 @@ +From 24607f114fd14f2f37e3e0cb3d47bce96e81e848 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +Date: Thu, 2 Oct 2014 16:51:18 -0400 +Subject: ring-buffer: Fix infinite spin in reading buffer + +From: "Steven Rostedt (Red Hat)" + +commit 24607f114fd14f2f37e3e0cb3d47bce96e81e848 upstream. + +Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page" +fixed one bug but in the process caused another one. The reset is to +update the header page, but that fix also changed the way the cached +reads were updated. The cache reads are used to test if an iterator +needs to be updated or not. + +A ring buffer iterator, when created, disables writes to the ring buffer +but does not stop other readers or consuming reads from happening. +Although all readers are synchronized via a lock, they are only +synchronized when in the ring buffer functions. Those functions may +be called by any number of readers. The iterator continues down when +its not interrupted by a consuming reader. If a consuming read +occurs, the iterator starts from the beginning of the buffer. + +The way the iterator sees that a consuming read has happened since +its last read is by checking the reader "cache". The cache holds the +last counts of the read and the reader page itself. + +Commit 651e22f2701b changed what was saved by the cache_read when +the rb_iter_reset() occurred, making the iterator never match the cache. +Then if the iterator calls rb_iter_reset(), it will go into an +infinite loop by checking if the cache doesn't match, doing the reset +and retrying, just to see that the cache still doesn't match! Which +should never happen as the reset is suppose to set the cache to the +current value and there's locks that keep a consuming reader from +having access to the data. + +Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page" +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/ring_buffer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -3375,7 +3375,7 @@ static void rb_iter_reset(struct ring_bu + iter->head = cpu_buffer->reader_page->read; + + iter->cache_reader_page = iter->head_page; +- iter->cache_read = iter->head; ++ iter->cache_read = cpu_buffer->read; + + if (iter->head) + iter->read_stamp = cpu_buffer->read_stamp; diff --git a/queue-3.16/series b/queue-3.16/series index 88b44efd92d..d6bb17c0e4d 100644 --- a/queue-3.16/series +++ b/queue-3.16/series @@ -1 +1,18 @@ udf-avoid-infinite-loop-when-processing-indirect-icbs.patch +asoc-ssm2602-do-not-hardcode-type-to-ssm2602.patch +asoc-core-fix-possible-zero_size_ptr-pointer-dereferencing-error.patch +perf-fix-perf-bug-in-fork.patch +mm-memcontrol-do-not-iterate-uninitialized-memcgs.patch +mm-migrate-close-race-between-migration-completion-and-mprotect.patch +i2c-qup-fix-order-of-runtime-pm-initialization.patch +i2c-rk3x-fix-0-length-write-transfers.patch +acpi-i915-update-the-condition-to-ignore-firmware-backlight-change-request.patch +cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch +cpufreq-pcc-cpufreq-fix-wait_event-under-spinlock.patch +md-raid5-disable-discard-by-default-due-to-safety-concerns.patch +drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch +fix-problem-recognizing-symlinks.patch +init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch +ring-buffer-fix-infinite-spin-in-reading-buffer.patch +uas-only-complain-about-missing-sg-if-all-other-checks-succeed.patch +uas-log-a-warning-when-we-cannot-use-uas-because-the-hcd-lacks-streams.patch diff --git a/queue-3.16/uas-log-a-warning-when-we-cannot-use-uas-because-the-hcd-lacks-streams.patch b/queue-3.16/uas-log-a-warning-when-we-cannot-use-uas-because-the-hcd-lacks-streams.patch new file mode 100644 index 00000000000..26cfe5927f1 --- /dev/null +++ b/queue-3.16/uas-log-a-warning-when-we-cannot-use-uas-because-the-hcd-lacks-streams.patch @@ -0,0 +1,48 @@ +From 43508be512661c905d0320ee73e0b65ef36d2459 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Fri, 25 Jul 2014 22:01:27 +0200 +Subject: uas: Log a warning when we cannot use uas because the hcd lacks streams + +From: Hans de Goede + +commit 43508be512661c905d0320ee73e0b65ef36d2459 upstream. + +So that an user who wants to use uas can see why he is not getting uas. + +Also move the check down so that we don't warn if there are other reasons +why uas cannot work. + +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/storage/uas-detect.h | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/drivers/usb/storage/uas-detect.h ++++ b/drivers/usb/storage/uas-detect.h +@@ -64,9 +64,6 @@ static int uas_use_uas_driver(struct usb + if (flags & US_FL_IGNORE_UAS) + return 0; + +- if (udev->speed >= USB_SPEED_SUPER && !hcd->can_do_streams) +- return 0; +- + alt = uas_find_uas_alt_setting(intf); + if (alt < 0) + return 0; +@@ -84,5 +81,14 @@ static int uas_use_uas_driver(struct usb + return 0; + } + ++ if (udev->speed >= USB_SPEED_SUPER && !hcd->can_do_streams) { ++ dev_warn(&udev->dev, ++ "USB controller %s does not support streams, which are required by the UAS driver.\n", ++ hcd_to_bus(hcd)->bus_name); ++ dev_warn(&udev->dev, ++ "Please try an other USB controller if you wish to use UAS.\n"); ++ return 0; ++ } ++ + return 1; + } diff --git a/queue-3.16/uas-only-complain-about-missing-sg-if-all-other-checks-succeed.patch b/queue-3.16/uas-only-complain-about-missing-sg-if-all-other-checks-succeed.patch new file mode 100644 index 00000000000..3f1c2b9c701 --- /dev/null +++ b/queue-3.16/uas-only-complain-about-missing-sg-if-all-other-checks-succeed.patch @@ -0,0 +1,70 @@ +From cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Fri, 25 Jul 2014 22:01:26 +0200 +Subject: uas: Only complain about missing sg if all other checks succeed + +From: Hans de Goede + +commit cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 upstream. + +Don't complain about controllers without sg support if there are other +reasons why uas cannot be used anyways. + +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/storage/uas-detect.h | 28 ++++++++++------------------ + 1 file changed, 10 insertions(+), 18 deletions(-) + +--- a/drivers/usb/storage/uas-detect.h ++++ b/drivers/usb/storage/uas-detect.h +@@ -9,32 +9,15 @@ static int uas_is_interface(struct usb_h + intf->desc.bInterfaceProtocol == USB_PR_UAS); + } + +-static int uas_isnt_supported(struct usb_device *udev) +-{ +- struct usb_hcd *hcd = bus_to_hcd(udev->bus); +- +- dev_warn(&udev->dev, "The driver for the USB controller %s does not " +- "support scatter-gather which is\n", +- hcd->driver->description); +- dev_warn(&udev->dev, "required by the UAS driver. Please try an" +- "alternative USB controller if you wish to use UAS.\n"); +- return -ENODEV; +-} +- + static int uas_find_uas_alt_setting(struct usb_interface *intf) + { + int i; +- struct usb_device *udev = interface_to_usbdev(intf); +- int sg_supported = udev->bus->sg_tablesize != 0; + + for (i = 0; i < intf->num_altsetting; i++) { + struct usb_host_interface *alt = &intf->altsetting[i]; + +- if (uas_is_interface(alt)) { +- if (!sg_supported) +- return uas_isnt_supported(udev); ++ if (uas_is_interface(alt)) + return alt->desc.bAlternateSetting; +- } + } + + return -ENODEV; +@@ -92,5 +75,14 @@ static int uas_use_uas_driver(struct usb + if (r < 0) + return 0; + ++ if (udev->bus->sg_tablesize == 0) { ++ dev_warn(&udev->dev, ++ "The driver for the USB controller %s does not support scatter-gather which is\n", ++ hcd->driver->description); ++ dev_warn(&udev->dev, ++ "required by the UAS driver. Please try an other USB controller if you wish to use UAS.\n"); ++ return 0; ++ } ++ + return 1; + }