--- /dev/null
+From 77076c7aac0184cae2d8a358cf6e6ed1f195fe3f Mon Sep 17 00:00:00 2001
+From: Aaron Lu <aaron.lu@intel.com>
+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 <aaron.lu@intel.com>
+
+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 <pali.rohar@gmail.com>
+Signed-off-by: Aaron Lu <aaron.lu@intel.com>
+Acked-by: Daniel Vetter <daniel@ffwll.ch>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 6596aa047b624aeec2ea321962cfdecf9953a383 Mon Sep 17 00:00:00 2001
+From: Xiubo Li <Li.Xiubo@freescale.com>
+Date: Sun, 28 Sep 2014 17:29:37 +0800
+Subject: ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error.
+
+From: Xiubo Li <Li.Xiubo@freescale.com>
+
+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 <Li.Xiubo@freescale.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fe2a08b3bf1a6e35c00e18843bc19aa1778432c3 Mon Sep 17 00:00:00 2001
+From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+Date: Mon, 29 Sep 2014 22:39:13 +0300
+Subject: ASoC: ssm2602: do not hardcode type to SSM2602
+
+From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+
+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 <stefan.kristiansson@saunalahti.fi>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Acked-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From d62dbf77f7dfaa6fb455b4b9828069a11965929c Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 26 Sep 2014 22:19:12 +0200
+Subject: cpufreq: integrator: fix integrator_cpufreq_remove return type
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <arnd@arndb.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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[] = {
--- /dev/null
+From e65b5ddba84634f31d42dfd86013f4c6be5e9e32 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Sat, 27 Sep 2014 21:56:08 +0200
+Subject: cpufreq: pcc-cpufreq: Fix wait_event() under spinlock
+
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+
+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:[<ffffffffa04d74d7>] 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:
+ [<ffffffff81589dbd>] dump_stack+0x4d/0x90
+ [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180
+ [<ffffffff8108e298>] __might_sleep+0x48/0xd0
+ [<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing);
+ [<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0
+ [<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock);
+ [<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0
+ [<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170
+ [<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0
+ [<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0
+ [<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720
+ [<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0
+ [<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210
+ [<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0
+ [<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110
+ [<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0
+ [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
+ [<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0
+ [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
+ [<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10
+ [<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0
+ [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
+ [<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0
+ [<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
+ [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
+ [<ffffffff81000298>] do_one_initcall+0xc8/0x1f0
+ [<ffffffff811a731d>] ? __vunmap+0x9d/0x100
+ [<ffffffff810eb9a0>] do_init_module+0x30/0x1b0
+ [<ffffffff810edfa6>] load_module+0x686/0x710
+ [<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0
+ [<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0
+ [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b
+
+Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
+Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 91e56499304f3d612053a9cf17f350868182c7d8 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 25 Sep 2014 10:13:12 +0100
+Subject: drm/i915: Flush the PTEs after updating them before suspend
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+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 <benjamin.widawsky@intel.com>
+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 <daniel.vetter@ffwll.ch>
+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 <chris@chris-wilson.co.uk>
+Cc: Takashi Iwai <tiwai@suse.de>
+Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Cc: Todd Previte <tprevite@gmail.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 19e81573fca7b87ced7701e01ba164b968d929bd Mon Sep 17 00:00:00 2001
+From: Steve French <smfrench@gmail.com>
+Date: Thu, 25 Sep 2014 01:26:55 -0500
+Subject: Fix problem recognizing symlinks
+
+From: Steve French <smfrench@gmail.com>
+
+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 <smfrench@gmail.com>
+Reviewed-by: Pavel Shilovsky <pshilovsky@samba.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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"},
--- /dev/null
+From 86b59bbfae2a895aa26b3d15f31b1a705dbfede1 Mon Sep 17 00:00:00 2001
+From: Andy Gross <agross@codeaurora.org>
+Date: Mon, 29 Sep 2014 17:00:51 -0500
+Subject: i2c: qup: Fix order of runtime pm initialization
+
+From: Andy Gross <agross@codeaurora.org>
+
+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 <agross@codeaurora.org>
+Reviewed-by: Felipe Balbi <balbi@ti.com>
+Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From cf27020d2f253bac6457d6833b97141030f0122a Mon Sep 17 00:00:00 2001
+From: Alexandru M Stan <amstan@chromium.org>
+Date: Wed, 1 Oct 2014 10:40:41 -0700
+Subject: i2c: rk3x: fix 0 length write transfers
+
+From: Alexandru M Stan <amstan@chromium.org>
+
+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 <dianders@chromium.org>
+Signed-off-by: Alexandru M Stan <amstan@chromium.org>
+Tested-by: Doug Anderson <dianders@chromium.org>
+Tested-by: Max Schwarz <max.schwarz@online.de>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f Mon Sep 17 00:00:00 2001
+From: Josh Triplett <josh@joshtriplett.org>
+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 <josh@joshtriplett.org>
+
+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 <josh@joshtriplett.org>
+Acked-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Thu, 2 Oct 2014 13:45:00 +1000
+Subject: md/raid5: disable 'DISCARD' by default due to safety concerns.
+
+From: NeilBrown <neilb@suse.de>
+
+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 <shli@kernel.org>
+Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
+Cc: Mike Snitzer <snitzer@redhat.com>
+Cc: Heinz Mauelshagen <heinzm@redhat.com>
+Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
+Acked-by: Mike Snitzer <snitzer@redhat.com>
+Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 &&
--- /dev/null
+From 2f7dd7a4100ad4affcb141605bef178ab98ccb18 Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Thu, 2 Oct 2014 16:16:57 -0700
+Subject: mm: memcontrol: do not iterate uninitialized memcgs
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+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 <hannes@cmpxchg.org>
+Cc: Tejun Heo <tj@kernel.org>
+Acked-by: Michal Hocko <mhocko@suse.cz>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
+ /*
--- /dev/null
+From d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 Mon Sep 17 00:00:00 2001
+From: Mel Gorman <mgorman@suse.de>
+Date: Thu, 2 Oct 2014 19:47:41 +0100
+Subject: mm: migrate: Close race between migration completion and mprotect
+
+From: Mel Gorman <mgorman@suse.de>
+
+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 <mgorman@suse.de>
+Acked-by: Rik van Riel <riel@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 6c72e3501d0d62fc064d3680e5234f3463ec5a86 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Thu, 2 Oct 2014 16:17:02 -0700
+Subject: perf: fix perf bug in fork()
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+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 <oleg@redhat.com>
+Reported-by: Oleg Nesterov <oleg@redhat.com>
+Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From 24607f114fd14f2f37e3e0cb3d47bce96e81e848 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+Date: Thu, 2 Oct 2014 16:51:18 -0400
+Subject: ring-buffer: Fix infinite spin in reading buffer
+
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+
+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 <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 43508be512661c905d0320ee73e0b65ef36d2459 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
