--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+Date: Fri, 3 Nov 2017 11:45:18 +0000
+Subject: arm-ccn: perf: Prevent module unload while PMU is in use
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+
+[ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ]
+
+When the PMU driver is built as a module, the perf expects the
+pmu->module to be valid, so that the driver is prevented from
+being unloaded while it is in use. Fix the CCN pmu driver to
+fill in this field.
+
+Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver")
+Cc: Pawel Moll <pawel.moll@arm.com>
+Cc: Will Deacon <will.deacon@arm.com>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/arm-ccn.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/bus/arm-ccn.c
++++ b/drivers/bus/arm-ccn.c
+@@ -1280,6 +1280,7 @@ static int arm_ccn_pmu_init(struct arm_c
+
+ /* Perf driver registration */
+ ccn->dt.pmu = (struct pmu) {
++ .module = THIS_MODULE,
+ .attr_groups = arm_ccn_pmu_attr_groups,
+ .task_ctx_nr = perf_invalid_context,
+ .event_init = arm_ccn_pmu_event_init,
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Neil Armstrong <narmstrong@baylibre.com>
+Date: Thu, 19 Oct 2017 12:31:09 +0200
+Subject: ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply
+
+From: Neil Armstrong <narmstrong@baylibre.com>
+
+
+[ Upstream commit e841ec956e539f4002f5e9fe9f9e904dcca12d5d ]
+
+Looking at the schematics, the USB Power Supply is shared between the
+two USB interfaces,
+If the usb0 fails to initialize, the second one won't have power.
+
+Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes")
+Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
++++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+@@ -301,6 +301,7 @@
+
+ &usb1_phy {
+ status = "okay";
++ phy-supply = <&usb_otg_pwr>;
+ };
+
+ &usb0 {
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Fri, 27 Oct 2017 09:33:41 -0700
+Subject: arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+
+[ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ]
+
+Upon upgrading to binutils 2.27, we found that our lz4 and gzip
+compressed kernel images were significantly larger, resulting is 10ms
+boot time regressions.
+
+As noted by Rahul:
+"aarch64 binaries uses RELA relocations, where each relocation entry
+includes an addend value. This is similar to x86_64. On x86_64, the
+addend values are also stored at the relocation offset for relative
+relocations. This is an optimization: in the case where code does not
+need to be relocated, the loader can simply skip processing relative
+relocations. In binutils-2.25, both bfd and gold linkers did this for
+x86_64, but only the gold linker did this for aarch64. The kernel build
+here is using the bfd linker, which stored zeroes at the relocation
+offsets for relative relocations. Since a set of zeroes compresses
+better than a set of non-zero addend values, this behavior was resulting
+in much better lz4 compression.
+
+The bfd linker in binutils-2.27 is now storing the actual addend values
+at the relocation offsets. The behavior is now consistent with what it
+does for x86_64 and what gold linker does for both architectures. The
+change happened in this upstream commit:
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613
+Since a bunch of zeroes got replaced by non-zero addend values, we see
+the side effect of lz4 compressed image being a bit bigger.
+
+To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs"
+flag can be used:
+$ LDFLAGS="--no-apply-dynamic-relocs" make
+With this flag, the compressed image size is back to what it was with
+binutils-2.25.
+
+If the kernel is using ASLR, there aren't additional runtime costs to
+--no-apply-dynamic-relocs, as the relocations will need to be applied
+again anyway after the kernel is relocated to a random address.
+
+If the kernel is not using ASLR, then presumably the current default
+behavior of the linker is better. Since the static linker performed the
+dynamic relocs, and the kernel is not moved to a different address at
+load time, it can skip applying the relocations all over again."
+
+Some measurements:
+
+$ ld -v
+GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117
+ ^
+$ ls -l vmlinux
+-rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux
+$ ls -l Image.lz4-dtb
+-rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb
+
+$ ld -v
+GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315
+ ^
+pre patch:
+$ ls -l vmlinux
+-rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux
+$ ls -l Image.lz4-dtb
+-rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb
+
+post patch:
+$ ls -l vmlinux
+-rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux
+$ ls -l Image.lz4-dtb
+-rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb
+
+By Siqi's measurement w/ gzip:
+binutils 2.27 with this patch (with --no-apply-dynamic-relocs):
+Image 41535488
+Image.gz 13404067
+
+binutils 2.27 without this patch (without --no-apply-dynamic-relocs):
+Image 41535488
+Image.gz 14125516
+
+Any compression scheme should be able to get better results from the
+longer runs of zeros, not just GZIP and LZ4.
+
+10ms boot time savings isn't anything to get excited about, but users of
+arm64+compression+bfd-2.27 should not have to pay a penalty for no
+runtime improvement.
+
+Reported-by: Gopinath Elanchezhian <gelanchezhian@google.com>
+Reported-by: Sindhuri Pentyala <spentyala@google.com>
+Reported-by: Wei Wang <wvw@google.com>
+Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Suggested-by: Rahul Chaudhry <rahulchaudhry@google.com>
+Suggested-by: Siqi Lin <siqilin@google.com>
+Suggested-by: Stephen Hines <srhines@google.com>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+[will: added comment to Makefile]
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/Makefile | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/Makefile
++++ b/arch/arm64/Makefile
+@@ -14,8 +14,12 @@ LDFLAGS_vmlinux :=-p --no-undefined -X
+ CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
+ GZFLAGS :=-9
+
+-ifneq ($(CONFIG_RELOCATABLE),)
+-LDFLAGS_vmlinux += -pie -shared -Bsymbolic
++ifeq ($(CONFIG_RELOCATABLE), y)
++# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour
++# for relative relocs, since this leads to better Image compression
++# with the relocation offsets always being zero.
++LDFLAGS_vmlinux += -pie -shared -Bsymbolic \
++ $(call ld-option, --no-apply-dynamic-relocs)
+ endif
+
+ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
+Date: Tue, 7 Nov 2017 16:16:19 +0530
+Subject: ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case
+
+From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
+
+
+[ Upstream commit f8e066521192c7debe59127d90abbe2773577e25 ]
+
+In the loop that adds the uuid_module to the uuid_list list, allocated
+memory is not properly freed in the error path free uuid_list whenever
+any of the memory allocation in the loop fails to avoid memory leak.
+
+Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
+Signed-off-by: Guneshwor Singh <guneshwor.o.singh@intel.com>
+Acked-By: Vinod Koul <vinod.koul@intel.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/intel/skylake/skl-sst-utils.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/sound/soc/intel/skylake/skl-sst-utils.c
++++ b/sound/soc/intel/skylake/skl-sst-utils.c
+@@ -251,6 +251,7 @@ int snd_skl_parse_uuids(struct sst_dsp *
+ struct uuid_module *module;
+ struct firmware stripped_fw;
+ unsigned int safe_file;
++ int ret = 0;
+
+ /* Get the FW pointer to derive ADSP header */
+ stripped_fw.data = fw->data;
+@@ -299,8 +300,10 @@ int snd_skl_parse_uuids(struct sst_dsp *
+
+ for (i = 0; i < num_entry; i++, mod_entry++) {
+ module = kzalloc(sizeof(*module), GFP_KERNEL);
+- if (!module)
+- return -ENOMEM;
++ if (!module) {
++ ret = -ENOMEM;
++ goto free_uuid_list;
++ }
+
+ uuid_bin = (uuid_le *)mod_entry->uuid.id;
+ memcpy(&module->uuid, uuid_bin, sizeof(module->uuid));
+@@ -311,8 +314,8 @@ int snd_skl_parse_uuids(struct sst_dsp *
+ size = sizeof(int) * mod_entry->instance_max_count;
+ module->instance_id = devm_kzalloc(ctx->dev, size, GFP_KERNEL);
+ if (!module->instance_id) {
+- kfree(module);
+- return -ENOMEM;
++ ret = -ENOMEM;
++ goto free_uuid_list;
+ }
+
+ list_add_tail(&module->list, &skl->uuid_list);
+@@ -323,6 +326,10 @@ int snd_skl_parse_uuids(struct sst_dsp *
+ }
+
+ return 0;
++
++free_uuid_list:
++ skl_freeup_uuid_list(skl);
++ return ret;
+ }
+
+ void skl_freeup_uuid_list(struct skl_sst *ctx)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+Date: Wed, 1 Nov 2017 07:16:58 +0000
+Subject: ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod
+
+From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+
+[ Upstream commit 21781e87881f9c420871b1d1f3f29d4cd7bffb10 ]
+
+SSI parent mod might be NULL. ssi_parent_mod() needs to care
+about it. Otherwise, it uses negative shift.
+This patch fixes it.
+
+Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/sh/rcar/ssi.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/sound/soc/sh/rcar/ssi.c
++++ b/sound/soc/sh/rcar/ssi.c
+@@ -198,10 +198,15 @@ static u32 rsnd_ssi_run_mods(struct rsnd
+ {
+ struct rsnd_mod *ssi_mod = rsnd_io_to_mod_ssi(io);
+ struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
++ u32 mods;
+
+- return rsnd_ssi_multi_slaves_runtime(io) |
+- 1 << rsnd_mod_id(ssi_mod) |
+- 1 << rsnd_mod_id(ssi_parent_mod);
++ mods = rsnd_ssi_multi_slaves_runtime(io) |
++ 1 << rsnd_mod_id(ssi_mod);
++
++ if (ssi_parent_mod)
++ mods |= 1 << rsnd_mod_id(ssi_parent_mod);
++
++ return mods;
+ }
+
+ u32 rsnd_ssi_multi_slaves_runtime(struct rsnd_dai_stream *io)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Brian Norris <briannorris@chromium.org>
+Date: Thu, 19 Oct 2017 11:45:19 -0700
+Subject: ath10k: fix build errors with !CONFIG_PM
+
+From: Brian Norris <briannorris@chromium.org>
+
+
+[ Upstream commit 20665a9076d48e9abd9a2db13d307f58f7ef6647 ]
+
+Build errors have been reported with CONFIG_PM=n:
+
+drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
+declaration of function 'ath10k_pci_suspend'
+[-Werror=implicit-function-declaration]
+
+drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
+declaration of function 'ath10k_pci_resume'
+[-Werror=implicit-function-declaration]
+
+These are caused by the combination of the following two commits:
+
+6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
+96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but
+disabled")
+
+Both build fine on their own.
+
+But now that ath10k_pci_pm_{suspend,resume}() is compiled
+unconditionally, we should also compile ath10k_pci_{suspend,resume}()
+unconditionally.
+
+And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they
+are trivial (empty), so we're not saving much space by compiling them
+out. And the alternatives would be to sprinkle more __maybe_unused, or
+spread the #ifdef's further.
+
+Build tested with the following combinations:
+CONFIG_PM=y && CONFIG_PM_SLEEP=y
+CONFIG_PM=y && CONFIG_PM_SLEEP=n
+CONFIG_PM=n
+
+Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled")
+Fixes: 096ad2a15fd8 ("Merge branch 'ath-next'")
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/ath10k/pci.c | 5 -----
+ 1 file changed, 5 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath10k/pci.c
++++ b/drivers/net/wireless/ath/ath10k/pci.c
+@@ -2577,8 +2577,6 @@ void ath10k_pci_hif_power_down(struct at
+ */
+ }
+
+-#ifdef CONFIG_PM
+-
+ static int ath10k_pci_hif_suspend(struct ath10k *ar)
+ {
+ /* Nothing to do; the important stuff is in the driver suspend. */
+@@ -2627,7 +2625,6 @@ static int ath10k_pci_resume(struct ath1
+
+ return ret;
+ }
+-#endif
+
+ static bool ath10k_pci_validate_cal(void *data, size_t size)
+ {
+@@ -2782,10 +2779,8 @@ static const struct ath10k_hif_ops ath10
+ .power_down = ath10k_pci_hif_power_down,
+ .read32 = ath10k_pci_read32,
+ .write32 = ath10k_pci_write32,
+-#ifdef CONFIG_PM
+ .suspend = ath10k_pci_hif_suspend,
+ .resume = ath10k_pci_hif_resume,
+-#endif
+ .fetch_cal_eeprom = ath10k_pci_hif_fetch_cal_eeprom,
+ };
+
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 4 Oct 2017 12:22:55 +0300
+Subject: ath10k: fix core PCI suspend when WoWLAN is supported but disabled
+
+From: Brian Norris <briannorris@chromium.org>
+
+
+[ Upstream commit 96378bd2c6cda5f04d0f6da2cd35d4670a982c38 ]
+
+For devices where the FW supports WoWLAN but user-space has not
+configured it, we don't do any PCI-specific suspend/resume operations,
+because mac80211 doesn't call drv_suspend() when !wowlan. This has
+particularly bad effects for some platforms, because we don't stop the
+power-save timer, and if this timer goes off after the PCI controller
+has suspended the link, Bad Things will happen.
+
+Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
+got some of this right, in that it understood there was a problem on
+non-WoWLAN firmware. But it forgot the $subject case.
+
+Fix this by moving all the PCI driver suspend/resume logic exclusively
+into the driver PM hooks. This shouldn't affect WoWLAN support much
+(this just gets executed later on).
+
+I would just as well kill the entirety of ath10k_hif_suspend(), as it's
+not even implemented on the USB or SDIO drivers. I expect that we don't
+need the callback, except to return "supported" (i.e., 0) or "not
+supported" (i.e., -EOPNOTSUPP).
+
+Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
+Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Cc: Ryan Hsu <ryanhsu@qti.qualcomm.com>
+Cc: Kalle Valo <kvalo@qca.qualcomm.com>
+Cc: Michal Kazior <michal.kazior@tieto.com>
+Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/ath10k/pci.c | 24 ++++++++++++++----------
+ 1 file changed, 14 insertions(+), 10 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath10k/pci.c
++++ b/drivers/net/wireless/ath/ath10k/pci.c
+@@ -2581,6 +2581,12 @@ void ath10k_pci_hif_power_down(struct at
+
+ static int ath10k_pci_hif_suspend(struct ath10k *ar)
+ {
++ /* Nothing to do; the important stuff is in the driver suspend. */
++ return 0;
++}
++
++static int ath10k_pci_suspend(struct ath10k *ar)
++{
+ /* The grace timer can still be counting down and ar->ps_awake be true.
+ * It is known that the device may be asleep after resuming regardless
+ * of the SoC powersave state before suspending. Hence make sure the
+@@ -2593,6 +2599,12 @@ static int ath10k_pci_hif_suspend(struct
+
+ static int ath10k_pci_hif_resume(struct ath10k *ar)
+ {
++ /* Nothing to do; the important stuff is in the driver resume. */
++ return 0;
++}
++
++static int ath10k_pci_resume(struct ath10k *ar)
++{
+ struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+ struct pci_dev *pdev = ar_pci->pdev;
+ u32 val;
+@@ -3401,11 +3413,7 @@ static __maybe_unused int ath10k_pci_pm_
+ struct ath10k *ar = dev_get_drvdata(dev);
+ int ret;
+
+- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
+- ar->running_fw->fw_file.fw_features))
+- return 0;
+-
+- ret = ath10k_hif_suspend(ar);
++ ret = ath10k_pci_suspend(ar);
+ if (ret)
+ ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
+
+@@ -3417,11 +3425,7 @@ static __maybe_unused int ath10k_pci_pm_
+ struct ath10k *ar = dev_get_drvdata(dev);
+ int ret;
+
+- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
+- ar->running_fw->fw_file.fw_features))
+- return 0;
+-
+- ret = ath10k_hif_resume(ar);
++ ret = ath10k_pci_resume(ar);
+ if (ret)
+ ath10k_warn(ar, "failed to resume hif: %d\n", ret);
+
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Miaoqing Pan <miaoqing@codeaurora.org>
+Date: Wed, 27 Sep 2017 09:13:34 +0800
+Subject: ath9k: fix tx99 potential info leak
+
+From: Miaoqing Pan <miaoqing@codeaurora.org>
+
+
+[ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ]
+
+When the user sets count to zero the string buffer would remain
+completely uninitialized which causes the kernel to parse its
+own stack data, potentially leading to an info leak. In addition
+to that, the string might be not terminated properly when the
+user data does not contain a 0-terminator.
+
+Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
+Reviewed-by: Christoph Böhmwalder <christoph@boehmwalder.at>
+Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/net/wireless/ath/ath9k/tx99.c
++++ b/drivers/net/wireless/ath/ath9k/tx99.c
+@@ -179,6 +179,9 @@ static ssize_t write_file_tx99(struct fi
+ ssize_t len;
+ int r;
+
++ if (count < 1)
++ return -EINVAL;
++
+ if (sc->cur_chan->nvifs > 1)
+ return -EOPNOTSUPP;
+
+@@ -186,6 +189,8 @@ static ssize_t write_file_tx99(struct fi
+ if (copy_from_user(buf, user_buf, len))
+ return -EFAULT;
+
++ buf[len] = '\0';
++
+ if (strtobool(buf, &start))
+ return -EINVAL;
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Liu Bo <bo.li.liu@oracle.com>
+Date: Fri, 3 Nov 2017 11:24:44 -0600
+Subject: badblocks: fix wrong return value in badblocks_set if badblocks are disabled
+
+From: Liu Bo <bo.li.liu@oracle.com>
+
+
+[ Upstream commit 39b4954c0a1556f8f7f1fdcf59a227117fcd8a0b ]
+
+MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if
+badblocks are disabled, otherwise, rdev_set_badblocks() will record
+superblock changes and return success in that case and md will fail to
+report an IO error which it should.
+
+This bug has existed since badblocks were introduced in commit
+9e0e252a048b ("badblocks: Add core badblock management code").
+
+Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
+Acked-by: Guoqing Jiang <gqjiang@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/badblocks.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/block/badblocks.c
++++ b/block/badblocks.c
+@@ -178,7 +178,7 @@ int badblocks_set(struct badblocks *bb,
+
+ if (bb->shift < 0)
+ /* badblocks are disabled */
+- return 0;
++ return 1;
+
+ if (bb->shift) {
+ /* round the start down, and the end up */
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Liang Chen <liangchen.linux@gmail.com>
+Date: Mon, 30 Oct 2017 14:46:35 -0700
+Subject: bcache: explicitly destroy mutex while exiting
+
+From: Liang Chen <liangchen.linux@gmail.com>
+
+
+[ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ]
+
+mutex_destroy does nothing most of time, but it's better to call
+it to make the code future proof and it also has some meaning
+for like mutex debug.
+
+As Coly pointed out in a previous review, bcache_exit() may not be
+able to handle all the references properly if userspace registers
+cache and backing devices right before bch_debug_init runs and
+bch_debug_init failes later. So not exposing userspace interface
+until everything is ready to avoid that issue.
+
+Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
+Reviewed-by: Michael Lyle <mlyle@lyle.org>
+Reviewed-by: Coly Li <colyli@suse.de>
+Reviewed-by: Eric Wheeler <bcache@linux.ewheeler.net>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/bcache/super.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/bcache/super.c
++++ b/drivers/md/bcache/super.c
+@@ -2085,6 +2085,7 @@ static void bcache_exit(void)
+ if (bcache_major)
+ unregister_blkdev(bcache_major, "bcache");
+ unregister_reboot_notifier(&reboot);
++ mutex_destroy(&bch_register_lock);
+ }
+
+ static int __init bcache_init(void)
+@@ -2103,14 +2104,15 @@ static int __init bcache_init(void)
+ bcache_major = register_blkdev(0, "bcache");
+ if (bcache_major < 0) {
+ unregister_reboot_notifier(&reboot);
++ mutex_destroy(&bch_register_lock);
+ return bcache_major;
+ }
+
+ if (!(bcache_wq = alloc_workqueue("bcache", WQ_MEM_RECLAIM, 0)) ||
+ !(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) ||
+- sysfs_create_files(bcache_kobj, files) ||
+ bch_request_init() ||
+- bch_debug_init(bcache_kobj))
++ bch_debug_init(bcache_kobj) ||
++ sysfs_create_files(bcache_kobj, files))
+ goto err;
+
+ return 0;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: "tang.junhui" <tang.junhui@zte.com.cn>
+Date: Mon, 30 Oct 2017 14:46:34 -0700
+Subject: bcache: fix wrong cache_misses statistics
+
+From: "tang.junhui" <tang.junhui@zte.com.cn>
+
+
+[ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ]
+
+Currently, Cache missed IOs are identified by s->cache_miss, but actually,
+there are many situations that missed IOs are not assigned a value for
+s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO
+(s->iop.bypass = 1), or the cache_bio allocate failed. In these situations,
+it will go to out_put or out_submit, and s->cache_miss is null, which leads
+bch_mark_cache_accounting() to treat this IO as a hit IO.
+
+[ML: applied by 3-way merge]
+
+Signed-off-by: tang.junhui <tang.junhui@zte.com.cn>
+Reviewed-by: Michael Lyle <mlyle@lyle.org>
+Reviewed-by: Coly Li <colyli@suse.de>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/bcache/request.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/bcache/request.c
++++ b/drivers/md/bcache/request.c
+@@ -463,6 +463,7 @@ struct search {
+ unsigned recoverable:1;
+ unsigned write:1;
+ unsigned read_dirty_data:1;
++ unsigned cache_missed:1;
+
+ unsigned long start_time;
+
+@@ -649,6 +650,7 @@ static inline struct search *search_allo
+
+ s->orig_bio = bio;
+ s->cache_miss = NULL;
++ s->cache_missed = 0;
+ s->d = d;
+ s->recoverable = 1;
+ s->write = op_is_write(bio_op(bio));
+@@ -767,7 +769,7 @@ static void cached_dev_read_done_bh(stru
+ struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
+
+ bch_mark_cache_accounting(s->iop.c, s->d,
+- !s->cache_miss, s->iop.bypass);
++ !s->cache_missed, s->iop.bypass);
+ trace_bcache_read(s->orig_bio, !s->cache_miss, s->iop.bypass);
+
+ if (s->iop.status)
+@@ -786,6 +788,8 @@ static int cached_dev_cache_miss(struct
+ struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
+ struct bio *miss, *cache_bio;
+
++ s->cache_missed = 1;
++
+ if (s->cache_miss || s->iop.bypass) {
+ miss = bio_next_split(bio, sectors, GFP_NOIO, s->d->bio_split);
+ ret = miss == bio ? MAP_DONE : MAP_CONTINUE;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Ming Lei <ming.lei@redhat.com>
+Date: Sat, 14 Oct 2017 17:22:25 +0800
+Subject: blk-mq-sched: dispatch from scheduler IFF progress is made in ->dispatch
+
+From: Ming Lei <ming.lei@redhat.com>
+
+
+[ Upstream commit 5e3d02bbafad38975099b5848f5ebadedcf7bb7e ]
+
+When the hw queue is busy, we shouldn't take requests from the scheduler
+queue any more, otherwise it is difficult to do IO merge.
+
+This patch fixes the awful IO performance on some SCSI devices(lpfc,
+qla2xxx, ...) when mq-deadline/kyber is used by not taking requests if
+hw queue is busy.
+
+Reviewed-by: Omar Sandoval <osandov@fb.com>
+Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-mq-sched.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/block/blk-mq-sched.c
++++ b/block/blk-mq-sched.c
+@@ -94,7 +94,7 @@ void blk_mq_sched_dispatch_requests(stru
+ struct request_queue *q = hctx->queue;
+ struct elevator_queue *e = q->elevator;
+ const bool has_sched_dispatch = e && e->type->ops.mq.dispatch_request;
+- bool did_work = false;
++ bool do_sched_dispatch = true;
+ LIST_HEAD(rq_list);
+
+ /* RCU or SRCU read lock is needed before checking quiesced flag */
+@@ -125,18 +125,18 @@ void blk_mq_sched_dispatch_requests(stru
+ */
+ if (!list_empty(&rq_list)) {
+ blk_mq_sched_mark_restart_hctx(hctx);
+- did_work = blk_mq_dispatch_rq_list(q, &rq_list);
++ do_sched_dispatch = blk_mq_dispatch_rq_list(q, &rq_list);
+ } else if (!has_sched_dispatch) {
+ blk_mq_flush_busy_ctxs(hctx, &rq_list);
+ blk_mq_dispatch_rq_list(q, &rq_list);
+ }
+
+ /*
+- * We want to dispatch from the scheduler if we had no work left
+- * on the dispatch list, OR if we did have work but weren't able
+- * to make progress.
++ * We want to dispatch from the scheduler if there was nothing
++ * on the dispatch list or we were able to dispatch from the
++ * dispatch list.
+ */
+- if (!did_work && has_sched_dispatch) {
++ if (do_sched_dispatch && has_sched_dispatch) {
+ do {
+ struct request *rq;
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Bartosz Chronowski <ext.bartosz.chronowski@tieto.com>
+Date: Thu, 26 Oct 2017 10:22:43 +0200
+Subject: Bluetooth: btusb: Add new NFA344A entry.
+
+From: Bartosz Chronowski <ext.bartosz.chronowski@tieto.com>
+
+
+[ Upstream commit 858ff38af77fc660092e82474ecc6ac135ed29fe ]
+
+This change allows proper low power mode entry in suspend.
+
+/sys/kernel/debug/usb/devices entry:
+T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=03 Dev#= 3 Spd=12 MxCh= 0
+D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=0489 ProdID=e09f Rev= 0.01
+C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+
+Signed-off-by: Bartosz Chronowski <ext.bartosz.chronowski@tieto.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btusb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -272,6 +272,7 @@ static const struct usb_device_id blackl
+ { USB_DEVICE(0x0cf3, 0xe301), .driver_info = BTUSB_QCA_ROME },
+ { USB_DEVICE(0x0cf3, 0xe360), .driver_info = BTUSB_QCA_ROME },
+ { USB_DEVICE(0x0489, 0xe092), .driver_info = BTUSB_QCA_ROME },
++ { USB_DEVICE(0x0489, 0xe09f), .driver_info = BTUSB_QCA_ROME },
+ { USB_DEVICE(0x0489, 0xe0a2), .driver_info = BTUSB_QCA_ROME },
+ { USB_DEVICE(0x04ca, 0x3011), .driver_info = BTUSB_QCA_ROME },
+ { USB_DEVICE(0x04ca, 0x3016), .driver_info = BTUSB_QCA_ROME },
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Ronald Tschalär <ronald@innovation.ch>
+Date: Wed, 25 Oct 2017 22:15:19 -0700
+Subject: Bluetooth: hci_ldisc: Fix another race when closing the tty.
+
+From: Ronald Tschalär <ronald@innovation.ch>
+
+
+[ Upstream commit 0338b1b393ec7910898e8f7b25b3bf31a7282e16 ]
+
+The following race condition still existed:
+
+ P1 P2
+ cancel_work_sync()
+ hci_uart_tx_wakeup()
+ hci_uart_write_work()
+ hci_uart_dequeue()
+ clear_bit(HCI_UART_PROTO_READY)
+ hci_unregister_dev(hdev)
+ hci_free_dev(hdev)
+ hu->proto->close(hu)
+ kfree(hu)
+ access to hdev and hu
+
+Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids
+this as any hci_uart_tx_wakeup() issued after the flag is cleared will
+detect that and not schedule further work.
+
+Signed-off-by: Ronald Tschalär <ronald@innovation.ch>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/hci_ldisc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/bluetooth/hci_ldisc.c
++++ b/drivers/bluetooth/hci_ldisc.c
+@@ -510,13 +510,13 @@ static void hci_uart_tty_close(struct tt
+ if (hdev)
+ hci_uart_close(hdev);
+
+- cancel_work_sync(&hu->write_work);
+-
+ if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
+ write_lock_irqsave(&hu->proto_lock, flags);
+ clear_bit(HCI_UART_PROTO_READY, &hu->flags);
+ write_unlock_irqrestore(&hu->proto_lock, flags);
+
++ cancel_work_sync(&hu->write_work);
++
+ if (hdev) {
+ if (test_bit(HCI_UART_REGISTERED, &hu->flags))
+ hci_unregister_dev(hdev);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Colin Ian King <colin.king@canonical.com>
+Date: Mon, 11 Sep 2017 16:15:28 +0100
+Subject: btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit
+
+From: Colin Ian King <colin.king@canonical.com>
+
+
+[ Upstream commit 3993b112dac968612b0b213ed59cb30f50b0015b ]
+
+There are checks on fs_info in __btrfs_panic to avoid dereferencing a
+null fs_info, however, there is a call to btrfs_crit that may also
+dereference a null fs_info. Fix this by adding a check to see if fs_info
+is null and only print the s_id if fs_info is non-null.
+
+Detected by CoverityScan CID#401973 ("Dereference after null check")
+
+Fixes: efe120a067c8 ("Btrfs: convert printk to btrfs_ and fix BTRFS prefix")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/super.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/super.c
++++ b/fs/btrfs/super.c
+@@ -202,7 +202,6 @@ static struct ratelimit_state printk_lim
+
+ void btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt, ...)
+ {
+- struct super_block *sb = fs_info->sb;
+ char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = "\0";
+ struct va_format vaf;
+ va_list args;
+@@ -228,7 +227,8 @@ void btrfs_printk(const struct btrfs_fs_
+ vaf.va = &args;
+
+ if (__ratelimit(ratelimit))
+- printk("%sBTRFS %s (device %s): %pV\n", lvl, type, sb->s_id, &vaf);
++ printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
++ fs_info ? fs_info->sb->s_id : "<unknown>", &vaf);
+
+ va_end(args);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Nikolay Borisov <nborisov@suse.com>
+Date: Thu, 28 Sep 2017 10:53:17 +0300
+Subject: btrfs: Explicitly handle btrfs_update_root failure
+
+From: Nikolay Borisov <nborisov@suse.com>
+
+
+[ Upstream commit 9417ebc8a676487c6ec8825f92fb28f7dbeb5f4b ]
+
+btrfs_udpate_root can fail and it aborts the transaction, the correct
+way to handle an aborted transaction is to explicitly end with
+btrfs_end_transaction. Even now the code is correct since
+btrfs_commit_transaction would handle an aborted transaction but this is
+more of an implementation detail. So let's be explicit in handling
+failure in btrfs_update_root.
+
+Furthermore btrfs_commit_transaction can also fail and by ignoring it's
+return value we could have left the in-memory copy of the root item in
+an inconsistent state. So capture the error value which allows us to
+correctly revert the RO/RW flags in case of commit failure.
+
+Signed-off-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/ioctl.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/ioctl.c
++++ b/fs/btrfs/ioctl.c
+@@ -1842,8 +1842,13 @@ static noinline int btrfs_ioctl_subvol_s
+
+ ret = btrfs_update_root(trans, fs_info->tree_root,
+ &root->root_key, &root->root_item);
++ if (ret < 0) {
++ btrfs_end_transaction(trans);
++ goto out_reset;
++ }
++
++ ret = btrfs_commit_transaction(trans);
+
+- btrfs_commit_transaction(trans);
+ out_reset:
+ if (ret)
+ btrfs_set_root_flags(&root->root_item, root_flags);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Anand Jain <anand.jain@oracle.com>
+Date: Sat, 14 Oct 2017 08:34:02 +0800
+Subject: btrfs: fix false EIO for missing device
+
+From: Anand Jain <anand.jain@oracle.com>
+
+
+[ Upstream commit 102ed2c5ff932439bbbe74c7bd63e6d5baa9f732 ]
+
+When one of the device is missing, bbio_error() takes care of setting
+the error status. And if its only IO that is pending in that stripe, it
+fails to check the status of the other IO at %bbio_error before setting
+the error %bi_status for the %orig_bio. Fix this by checking if
+%bbio->error has exceeded the %bbio->max_errors.
+
+Reproducer as below fdatasync error is seen intermittently.
+
+ mount -o degraded /dev/sdc /btrfs
+ dd status=none if=/dev/zero of=$(mktemp /btrfs/XXX) bs=4096 count=1 conv=fdatasync
+
+ dd: fdatasync failed for ‘/btrfs/LSe’: Input/output error
+
+ The reason for the intermittences of the problem is because
+ the following conditions have to be met, which depends on timing:
+ In btrfs_map_bio()
+ - the RAID1 the missing device has to be at %dev_nr = 1
+ In bbio_error()
+ . before bbio_error() is called the bio of the not-missing
+ device at %dev_nr = 0 must be completed so that the below
+ condition is true
+ if (atomic_dec_and_test(&bbio->stripes_pending)) {
+
+Signed-off-by: Anand Jain <anand.jain@oracle.com>
+Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/volumes.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -6144,7 +6144,10 @@ static void bbio_error(struct btrfs_bio
+
+ btrfs_io_bio(bio)->mirror_num = bbio->mirror_num;
+ bio->bi_iter.bi_sector = logical >> 9;
+- bio->bi_status = BLK_STS_IOERR;
++ if (atomic_read(&bbio->error) > bbio->max_errors)
++ bio->bi_status = BLK_STS_IOERR;
++ else
++ bio->bi_status = BLK_STS_OK;
+ btrfs_end_bbio(bbio, bio);
+ }
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sun, 10 Sep 2017 13:19:38 +0200
+Subject: btrfs: tests: Fix a memory leak in error handling path in 'run_test()'
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+
+[ Upstream commit 9ca2e97fa3c3216200afe35a3b111ec51cc796d2 ]
+
+If 'btrfs_alloc_path()' fails, we must free the resources already
+allocated, as done in the other error handling paths in this function.
+
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/tests/free-space-tree-tests.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/tests/free-space-tree-tests.c
++++ b/fs/btrfs/tests/free-space-tree-tests.c
+@@ -500,7 +500,8 @@ static int run_test(test_func_t test_fun
+ path = btrfs_alloc_path();
+ if (!path) {
+ test_msg("Couldn't allocate path\n");
+- return -ENOMEM;
++ ret = -ENOMEM;
++ goto out;
+ }
+
+ ret = add_block_group_free_space(&trans, root->fs_info, cache);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Anand Jain <anand.jain@oracle.com>
+Date: Thu, 28 Sep 2017 14:51:09 +0800
+Subject: btrfs: undo writable superblocke when sprouting fails
+
+From: Anand Jain <anand.jain@oracle.com>
+
+
+[ Upstream commit 0af2c4bf5a012a40a2f9230458087d7f068339d0 ]
+
+When new device is being added to seed FS, seed FS is marked writable,
+but when we fail to bring in the new device, we missed to undo the
+writable part. This patch fixes it.
+
+Signed-off-by: Anand Jain <anand.jain@oracle.com>
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/volumes.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -2501,6 +2501,8 @@ int btrfs_init_new_device(struct btrfs_f
+ return ret;
+
+ error_trans:
++ if (seeding_dev)
++ sb->s_flags |= MS_RDONLY;
+ btrfs_end_transaction(trans);
+ rcu_string_free(device->name);
+ btrfs_sysfs_rm_device_link(fs_info->fs_devices, device);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Leo Yan <leo.yan@linaro.org>
+Date: Fri, 1 Sep 2017 08:47:14 +0800
+Subject: clk: hi6220: mark clock cs_atb_syspll as critical
+
+From: Leo Yan <leo.yan@linaro.org>
+
+
+[ Upstream commit d2a3671ebe6479483a12f94fcca63c058d95ad64 ]
+
+Clock cs_atb_syspll is pll used for coresight trace bus; when clock
+cs_atb_syspll is disabled and operates its child clock node cs_atb
+results in system hang. So mark clock cs_atb_syspll as critical to
+keep it enabled.
+
+Cc: Guodong Xu <guodong.xu@linaro.org>
+Cc: Zhangfei Gao <zhangfei.gao@linaro.org>
+Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
+Signed-off-by: Leo Yan <leo.yan@linaro.org>
+Signed-off-by: Michael Turquette <mturquette@baylibre.com>
+Link: lkml.kernel.org/r/1504226835-2115-2-git-send-email-leo.yan@linaro.org
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/hisilicon/clk-hi6220.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/hisilicon/clk-hi6220.c
++++ b/drivers/clk/hisilicon/clk-hi6220.c
+@@ -145,7 +145,7 @@ static struct hisi_gate_clock hi6220_sep
+ { HI6220_BBPPLL_SEL, "bbppll_sel", "pll0_bbp_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 9, 0, },
+ { HI6220_MEDIA_PLL_SRC, "media_pll_src", "pll_media_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 10, 0, },
+ { HI6220_MMC2_SEL, "mmc2_sel", "mmc2_mux1", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 11, 0, },
+- { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 12, 0, },
++ { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IS_CRITICAL, 0x270, 12, 0, },
+ };
+
+ static struct hisi_mux_clock hi6220_mux_clks_sys[] __initdata = {
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Adriana Reus <adriana.reus@nxp.com>
+Date: Mon, 2 Oct 2017 13:32:10 +0300
+Subject: clk: imx: imx7d: Fix parent clock for OCRAM_CLK
+
+From: Adriana Reus <adriana.reus@nxp.com>
+
+
+[ Upstream commit edc5a8e754aba9c6eaeddd18cb1e72462f99b16c ]
+
+The parent of OCRAM_CLK should be axi_main_root_clk
+and not axi_post_div.
+
+before:
+
+ axi_src 1 1 332307692 0 0
+ axi_cg 1 1 332307692 0 0
+ axi_pre_div 1 1 332307692 0 0
+ axi_post_div 1 1 332307692 0 0
+ ocram_clk 0 0 332307692 0 0
+ main_axi_root_clk 1 1 332307692 0 0
+
+after:
+
+ axi_src 1 1 332307692 0 0
+ axi_cg 1 1 332307692 0 0
+ axi_pre_div 1 1 332307692 0 0
+ axi_post_div 1 1 332307692 0 0
+ main_axi_root_clk 1 1 332307692 0 0
+ ocram_clk 0 0 332307692 0 0
+
+Reference Doc: i.MX 7D Reference Manual - Chap 5, p 516
+(https://www.nxp.com/docs/en/reference-manual/IMX7DRM.pdf)
+
+Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support")
+Signed-off-by: Adriana Reus <adriana.reus@nxp.com>
+Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/imx/clk-imx7d.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/imx/clk-imx7d.c
++++ b/drivers/clk/imx/clk-imx7d.c
+@@ -797,7 +797,7 @@ static void __init imx7d_clocks_init(str
+ clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk", "axi_post_div", base + 0x4040, 0);
+ clks[IMX7D_DISP_AXI_ROOT_CLK] = imx_clk_gate4("disp_axi_root_clk", "disp_axi_post_div", base + 0x4050, 0);
+ clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk", "enet_axi_post_div", base + 0x4060, 0);
+- clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "axi_post_div", base + 0x4110, 0);
++ clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "main_axi_root_clk", base + 0x4110, 0);
+ clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk", base + 0x4120, 0);
+ clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk", "dram_post_div", base + 0x4130, 0);
+ clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+Date: Tue, 1 Aug 2017 12:40:07 +0200
+Subject: clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU
+
+From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+
+
+[ Upstream commit c68ee58d9ee7b856ac722f18f4f26579c8fbd2b4 ]
+
+On i.MX6 SoCs without VPU (in my case MCIMX6D4AVT10AC), the hdmi driver
+fails to probe:
+
+[ 2.540030] dwhdmi-imx 120000.hdmi: Unsupported HDMI controller
+(0000:00:00)
+[ 2.548199] imx-drm display-subsystem: failed to bind 120000.hdmi
+(ops dw_hdmi_imx_ops): -19
+[ 2.557403] imx-drm display-subsystem: master bind failed: -19
+
+That's because hdmi_isfr's parent, video_27m, is not correctly ungated.
+As explained in commit 5ccc248cc537 ("ARM: imx6q: clk: Add support for
+mipi_core_cfg clock as a shared clock gate"), video_27m is gated by
+CCM_CCGR3[CG8].
+
+On i.MX6 SoCs with VPU, the hdmi is working thanks to the
+CCM_CMEOR[mod_en_ov_vpu] bit which makes the video_27m ungated whatever
+is in CCM_CCGR3[CG8]. The issue can be reproduced by setting
+CCMEOR[mod_en_ov_vpu] to 0.
+
+Make the HDMI work in every case by setting hdmi_isfr's parent to
+mipi_core_cfg.
+
+Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
+Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/imx/clk-imx6q.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/imx/clk-imx6q.c
++++ b/drivers/clk/imx/clk-imx6q.c
+@@ -761,7 +761,7 @@ static void __init imx6q_clocks_init(str
+ clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24);
+ clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core", "gpu3d_core_podf", base + 0x6c, 26);
+ clk[IMX6QDL_CLK_HDMI_IAHB] = imx_clk_gate2("hdmi_iahb", "ahb", base + 0x70, 0);
+- clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "video_27m", base + 0x70, 4);
++ clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "mipi_core_cfg", base + 0x70, 4);
+ clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1", "ipg_per", base + 0x70, 6);
+ clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2", "ipg_per", base + 0x70, 8);
+ clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3", "ipg_per", base + 0x70, 10);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Chen Zhong <chen.zhong@mediatek.com>
+Date: Thu, 5 Oct 2017 11:50:23 +0800
+Subject: clk: mediatek: add the option for determining PLL source clock
+
+From: Chen Zhong <chen.zhong@mediatek.com>
+
+
+[ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ]
+
+Since the previous setup always sets the PLL using crystal 26MHz, this
+doesn't always happen in every MediaTek platform. So the patch added
+flexibility for assigning extra member for determining the PLL source
+clock.
+
+Signed-off-by: Chen Zhong <chen.zhong@mediatek.com>
+Signed-off-by: Sean Wang <sean.wang@mediatek.com>
+Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/mediatek/clk-mtk.h | 1 +
+ drivers/clk/mediatek/clk-pll.c | 5 ++++-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/clk/mediatek/clk-mtk.h
++++ b/drivers/clk/mediatek/clk-mtk.h
+@@ -216,6 +216,7 @@ struct mtk_pll_data {
+ uint32_t pcw_reg;
+ int pcw_shift;
+ const struct mtk_pll_div_table *div_table;
++ const char *parent_name;
+ };
+
+ void mtk_clk_register_plls(struct device_node *node,
+--- a/drivers/clk/mediatek/clk-pll.c
++++ b/drivers/clk/mediatek/clk-pll.c
+@@ -303,7 +303,10 @@ static struct clk *mtk_clk_register_pll(
+ init.name = data->name;
+ init.flags = (data->flags & PLL_AO) ? CLK_IS_CRITICAL : 0;
+ init.ops = &mtk_pll_ops;
+- init.parent_names = &parent_name;
++ if (data->parent_name)
++ init.parent_names = &data->parent_name;
++ else
++ init.parent_names = &parent_name;
+ init.num_parents = 1;
+
+ clk = clk_register(NULL, &pll->hw);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+Date: Tue, 19 Sep 2017 04:48:10 +0200
+Subject: clk: tegra: Fix cclk_lp divisor register
+
+From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+
+
+[ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ]
+
+According to comments in code and common sense, cclk_lp uses its
+own divisor, not cclk_g's.
+
+Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30")
+Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/tegra/clk-tegra30.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/tegra/clk-tegra30.c
++++ b/drivers/clk/tegra/clk-tegra30.c
+@@ -964,7 +964,7 @@ static void __init tegra30_super_clk_ini
+ * U71 divider of cclk_lp.
+ */
+ clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3",
+- clk_base + SUPER_CCLKG_DIVIDER, 0,
++ clk_base + SUPER_CCLKLP_DIVIDER, 0,
+ TEGRA_DIVIDER_INT, 16, 8, 1, NULL);
+ clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL);
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Nicolin Chen <nicoleotsuka@gmail.com>
+Date: Fri, 15 Sep 2017 12:10:13 -0700
+Subject: clk: tegra: Use readl_relaxed_poll_timeout_atomic() in tegra210_clock_init()
+
+From: Nicolin Chen <nicoleotsuka@gmail.com>
+
+
+[ Upstream commit 22ef01a203d27fee8b7694020b7e722db7efd2a7 ]
+
+Below is the call trace of tegra210_init_pllu() function:
+ start_kernel()
+ -> time_init()
+ --> of_clk_init()
+ ---> tegra210_clock_init()
+ ----> tegra210_pll_init()
+ -----> tegra210_init_pllu()
+
+Because the preemption is disabled in the start_kernel before calling
+time_init, tegra210_init_pllu is actually in an atomic context while
+it includes a readl_relaxed_poll_timeout that might sleep.
+
+So this patch just changes this readl_relaxed_poll_timeout() to its
+atomic version.
+
+Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
+Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/tegra/clk-tegra210.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/clk/tegra/clk-tegra210.c
++++ b/drivers/clk/tegra/clk-tegra210.c
+@@ -2566,8 +2566,8 @@ static int tegra210_enable_pllu(void)
+ reg |= PLL_ENABLE;
+ writel(reg, clk_base + PLLU_BASE);
+
+- readl_relaxed_poll_timeout(clk_base + PLLU_BASE, reg,
+- reg & PLL_BASE_LOCK, 2, 1000);
++ readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
++ reg & PLL_BASE_LOCK, 2, 1000);
+ if (!(reg & PLL_BASE_LOCK)) {
+ pr_err("Timed out waiting for PLL_U to lock\n");
+ return -ETIMEDOUT;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Robert Baronescu <robert.baronescu@nxp.com>
+Date: Tue, 10 Oct 2017 13:22:00 +0300
+Subject: crypto: tcrypt - fix buffer lengths in test_aead_speed()
+
+From: Robert Baronescu <robert.baronescu@nxp.com>
+
+
+[ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ]
+
+Fix the way the length of the buffers used for
+encryption / decryption are computed.
+For e.g. in case of encryption, input buffer does not contain
+an authentication tag.
+
+Signed-off-by: Robert Baronescu <robert.baronescu@nxp.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/tcrypt.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/crypto/tcrypt.c
++++ b/crypto/tcrypt.c
+@@ -340,7 +340,7 @@ static void test_aead_speed(const char *
+ }
+
+ sg_init_aead(sg, xbuf,
+- *b_size + (enc ? authsize : 0));
++ *b_size + (enc ? 0 : authsize));
+
+ sg_init_aead(sgout, xoutbuf,
+ *b_size + (enc ? authsize : 0));
+@@ -348,7 +348,9 @@ static void test_aead_speed(const char *
+ sg_set_buf(&sg[0], assoc, aad_size);
+ sg_set_buf(&sgout[0], assoc, aad_size);
+
+- aead_request_set_crypt(req, sg, sgout, *b_size, iv);
++ aead_request_set_crypt(req, sg, sgout,
++ *b_size + (enc ? 0 : authsize),
++ iv);
+ aead_request_set_ad(req, aad_size);
+
+ if (secs)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Ross Zwisler <ross.zwisler@linux.intel.com>
+Date: Wed, 18 Oct 2017 12:21:55 -0600
+Subject: dev/dax: fix uninitialized variable build warning
+
+From: Ross Zwisler <ross.zwisler@linux.intel.com>
+
+
+[ Upstream commit 0a3ff78699d1817e711441715d22665475466036 ]
+
+Fix this build warning:
+
+warning: 'phys' may be used uninitialized in this function
+[-Wuninitialized]
+
+As reported here:
+
+https://lkml.org/lkml/2017/10/16/152
+http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/
+
+Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dax/device.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/dax/device.c
++++ b/drivers/dax/device.c
+@@ -222,7 +222,8 @@ __weak phys_addr_t dax_pgoff_to_phys(str
+ unsigned long size)
+ {
+ struct resource *res;
+- phys_addr_t phys;
++ /* gcc-4.6.3-nolibc for i386 complains that this is uninitialized */
++ phys_addr_t uninitialized_var(phys);
+ int i;
+
+ for (i = 0; i < dev_dax->num_resources; i++) {
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
+Date: Thu, 19 Oct 2017 01:15:13 +0000
+Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue
+
+From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
+
+
+[ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ]
+
+SYS/RT/Audio DMAC includes independent data buffers for reading
+and writing. Therefore, the read transfer counter and write transfer
+counter have different values.
+TCR indicates read counter, and TCRB indicates write counter.
+The relationship is like below.
+
+ TCR TCRB
+[SOURCE] -> [DMAC] -> [SINK]
+
+In the MEM_TO_DEV direction, what really matters is how much data has
+been written to the device. If the DMA is interrupted between read and
+write, then, the data doesn't end up in the destination, so shouldn't
+be counted. TCRB is thus the register we should use in this cases.
+
+In the DEV_TO_MEM direction, the situation is more complex. Both the
+read and write side are important. What matters from a data consumer
+point of view is how much data has been written to memory.
+On the other hand, if the transfer is interrupted between read and
+write, we'll end up losing data. It can also be important to report.
+
+In the MEM_TO_MEM direction, what matters is of course how much data
+has been written to memory from data consumer point of view.
+Here, because read and write have independent data buffers, it will
+take a while for TCR and TCRB to become equal. Thus we should check
+TCRB in this case, too.
+
+Thus, all cases we should check TCRB instead of TCR.
+
+Without this patch, Sound Capture has noise after PluseAudio support
+(= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because
+the recorder will use wrong residue counter which indicates transferred
+from sound device, but in reality the data was not yet put to memory
+and recorder will record it.
+
+Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
+[Kuninori: added detail information in log]
+Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Vinod Koul <vinod.koul@intel.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/sh/rcar-dmac.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/dma/sh/rcar-dmac.c
++++ b/drivers/dma/sh/rcar-dmac.c
+@@ -1310,7 +1310,7 @@ static unsigned int rcar_dmac_chan_get_r
+ }
+
+ /* Add the residue for the current chunk. */
+- residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift;
++ residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
+
+ return residue;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Date: Wed, 8 Nov 2017 12:02:25 +0200
+Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
+
+From: Peter Ujfalusi <peter.ujfalusi@ti.com>
+
+
+[ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ]
+
+The used 0x1f mask is only valid for am335x family of SoC, different family
+using this type of crossbar might have different number of electable
+events. In case of am43xx family 0x3f mask should have been used for
+example.
+Instead of trying to handle each family's mask, just use u8 type to store
+the mux value since the event offsets are aligned to byte offset.
+
+Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
+Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Signed-off-by: Vinod Koul <vinod.koul@intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/ti-dma-crossbar.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/dma/ti-dma-crossbar.c
++++ b/drivers/dma/ti-dma-crossbar.c
+@@ -49,12 +49,12 @@ struct ti_am335x_xbar_data {
+
+ struct ti_am335x_xbar_map {
+ u16 dma_line;
+- u16 mux_val;
++ u8 mux_val;
+ };
+
+-static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val)
++static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
+ {
+- writeb_relaxed(val & 0x1f, iomem + event);
++ writeb_relaxed(val, iomem + event);
+ }
+
+ static void ti_am335x_xbar_free(struct device *dev, void *route_data)
+@@ -105,7 +105,7 @@ static void *ti_am335x_xbar_route_alloca
+ }
+
+ map->dma_line = (u16)dma_spec->args[0];
+- map->mux_val = (u16)dma_spec->args[2];
++ map->mux_val = (u8)dma_spec->args[2];
+
+ dma_spec->args[2] = 0;
+ dma_spec->args_count = 2;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Pixel Ding <Pixel.Ding@amd.com>
+Date: Wed, 8 Nov 2017 10:20:01 +0800
+Subject: drm/amdgpu: bypass lru touch for KIQ ring submission
+
+From: Pixel Ding <Pixel.Ding@amd.com>
+
+
+[ Upstream commit dce1e131dd4dc68099ff1b70aa03cd2d0acf8639 ]
+
+KIQ ring submission is used for register accessing on SRIOV
+VF that could happen both in irq enabled and irq disabled cases.
+Inversion lock could happen on adev->ring_lru_list_lock, while
+this operation is useless and just adds overhead in this use
+case.
+
+Signed-off-by: Pixel Ding <Pixel.Ding@amd.com>
+Reviewed-by: Monk Liu <Monk.Liu@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+@@ -136,7 +136,8 @@ void amdgpu_ring_commit(struct amdgpu_ri
+ if (ring->funcs->end_use)
+ ring->funcs->end_use(ring);
+
+- amdgpu_ring_lru_touch(ring->adev, ring);
++ if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ)
++ amdgpu_ring_lru_touch(ring->adev, ring);
+ }
+
+ /**
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+Date: Thu, 9 Nov 2017 18:09:33 +0100
+Subject: fbdev: controlfb: Add missing modes to fix out of bounds access
+
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+
+
+[ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ]
+
+Dan's static analysis says:
+
+ drivers/video/fbdev/controlfb.c:560 control_setup()
+ error: buffer overflow 'control_mac_modes' 20 <= 21
+
+Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22,
+which may lead to an out of bounds read when parsing vmode commandline
+options.
+
+The bug was introduced in v2.4.5.6, when 2 new modes were added to
+macmodes.h, but control_mac_modes[] wasn't updated:
+
+https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.5.2&id=29f279c764808560eaceb88fef36cbc35c529aad
+
+Augment control_mac_modes[] with the two new video modes to fix this.
+
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/controlfb.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/video/fbdev/controlfb.h
++++ b/drivers/video/fbdev/controlfb.h
+@@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod
+ {{ 1, 2}}, /* 1152x870, 75Hz */
+ {{ 0, 1}}, /* 1280x960, 75Hz */
+ {{ 0, 1}}, /* 1280x1024, 75Hz */
++ {{ 1, 2}}, /* 1152x768, 60Hz */
++ {{ 0, 1}}, /* 1600x1024, 60Hz */
+ };
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Bob Peterson <rpeterso@redhat.com>
+Date: Wed, 20 Sep 2017 08:30:04 -0500
+Subject: GFS2: Take inode off order_write list when setting jdata flag
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+
+[ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ]
+
+This patch fixes a deadlock caused when the jdata flag is set for
+inodes that are already on the ordered write list. Since it is
+on the ordered write list, log_flush calls gfs2_ordered_write which
+calls filemap_fdatawrite. But since the inode had the jdata flag
+set, that calls gfs2_jdata_writepages, which tries to start a new
+transaction. A new transaction cannot be started because it tries
+to acquire the log_flush rwsem which is already locked by the log
+flush operation.
+
+The bottom line is: We cannot switch an inode from ordered to jdata
+until we eliminate any ordered data pages (via log flush) or any
+log_flush operation afterward will create the circular dependency
+above. So we need to flush the log before setting the diskflags to
+switch the file mode, then we need to remove the inode from the
+ordered writes list.
+
+Before this patch, the log flush was done for jdata->ordered, but
+that's wrong. If we're going from jdata to ordered, we don't need
+to call gfs2_log_flush because the call to filemap_fdatawrite will
+do it for us:
+
+ filemap_fdatawrite() -> __filemap_fdatawrite_range()
+ __filemap_fdatawrite_range() -> do_writepages()
+ do_writepages() -> gfs2_jdata_writepages()
+ gfs2_jdata_writepages() -> gfs2_log_flush()
+
+This patch modifies function do_gfs2_set_flags so that if a file
+has its jdata flag set, and it's already on the ordered write list,
+the log will be flushed and it will be removed from the list
+before setting the flag.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Acked-by: Abhijith Das <adas@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/gfs2/file.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/gfs2/file.c
++++ b/fs/gfs2/file.c
+@@ -256,7 +256,7 @@ static int do_gfs2_set_flags(struct file
+ goto out;
+ }
+ if ((flags ^ new_flags) & GFS2_DIF_JDATA) {
+- if (flags & GFS2_DIF_JDATA)
++ if (new_flags & GFS2_DIF_JDATA)
+ gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH);
+ error = filemap_fdatawrite(inode->i_mapping);
+ if (error)
+@@ -264,6 +264,8 @@ static int do_gfs2_set_flags(struct file
+ error = filemap_fdatawait(inode->i_mapping);
+ if (error)
+ goto out;
++ if (new_flags & GFS2_DIF_JDATA)
++ gfs2_ordered_del_inode(ip);
+ }
+ error = gfs2_trans_begin(sdp, RES_DINODE, 0);
+ if (error)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+Date: Fri, 10 Nov 2017 10:01:43 +0100
+Subject: HID: cp2112: fix broken gpio_direction_input callback
+
+From: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+
+
+[ Upstream commit 7da85fbf1c87d4f73621e0e7666a3387497075a9 ]
+
+When everything goes smoothly, ret is set to 0 which makes the function
+to return EIO error.
+
+Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
+Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/hid-cp2112.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/hid/hid-cp2112.c
++++ b/drivers/hid/hid-cp2112.c
+@@ -196,6 +196,8 @@ static int cp2112_gpio_direction_input(s
+ HID_REQ_GET_REPORT);
+ if (ret != CP2112_GPIO_CONFIG_LENGTH) {
+ hid_err(hdev, "error requesting GPIO config: %d\n", ret);
++ if (ret >= 0)
++ ret = -EIO;
+ goto exit;
+ }
+
+@@ -205,8 +207,10 @@ static int cp2112_gpio_direction_input(s
+ ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
+ CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
+ HID_REQ_SET_REPORT);
+- if (ret < 0) {
++ if (ret != CP2112_GPIO_CONFIG_LENGTH) {
+ hid_err(hdev, "error setting GPIO config: %d\n", ret);
++ if (ret >= 0)
++ ret = -EIO;
+ goto exit;
+ }
+
+@@ -214,7 +218,7 @@ static int cp2112_gpio_direction_input(s
+
+ exit:
+ mutex_unlock(&dev->lock);
+- return ret < 0 ? ret : -EIO;
++ return ret;
+ }
+
+ static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Parav Pandit <parav@mellanox.com>
+Date: Mon, 16 Oct 2017 08:45:16 +0300
+Subject: IB/core: Fix calculation of maximum RoCE MTU
+
+From: Parav Pandit <parav@mellanox.com>
+
+
+[ Upstream commit 99260132fde7bddc6e0132ce53da94d1c9ccabcb ]
+
+The original code only took into consideration the largest header
+possible after the IB_BTH_BYTES. This was incorrect, as the largest
+possible header size is the largest possible combination of headers we
+might run into. The new code accounts for all possible headers in the
+largest possible combination and subtracts that from the MTU to make
+sure that all packets will fit on the wire.
+
+Link: https://www.spinics.net/lists/linux-rdma/msg54558.html
+Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices")
+Signed-off-by: Parav Pandit <parav@mellanox.com>
+Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
+Reported-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/rdma/ib_addr.h | 7 ++++---
+ include/rdma/ib_pack.h | 19 +++++++++++--------
+ 2 files changed, 15 insertions(+), 11 deletions(-)
+
+--- a/include/rdma/ib_addr.h
++++ b/include/rdma/ib_addr.h
+@@ -245,10 +245,11 @@ static inline void rdma_addr_set_dgid(st
+ static inline enum ib_mtu iboe_get_mtu(int mtu)
+ {
+ /*
+- * reduce IB headers from effective IBoE MTU. 28 stands for
+- * atomic header which is the biggest possible header after BTH
++ * Reduce IB headers from effective IBoE MTU.
+ */
+- mtu = mtu - IB_GRH_BYTES - IB_BTH_BYTES - 28;
++ mtu = mtu - (IB_GRH_BYTES + IB_UDP_BYTES + IB_BTH_BYTES +
++ IB_EXT_XRC_BYTES + IB_EXT_ATOMICETH_BYTES +
++ IB_ICRC_BYTES);
+
+ if (mtu >= ib_mtu_enum_to_int(IB_MTU_4096))
+ return IB_MTU_4096;
+--- a/include/rdma/ib_pack.h
++++ b/include/rdma/ib_pack.h
+@@ -37,14 +37,17 @@
+ #include <uapi/linux/if_ether.h>
+
+ enum {
+- IB_LRH_BYTES = 8,
+- IB_ETH_BYTES = 14,
+- IB_VLAN_BYTES = 4,
+- IB_GRH_BYTES = 40,
+- IB_IP4_BYTES = 20,
+- IB_UDP_BYTES = 8,
+- IB_BTH_BYTES = 12,
+- IB_DETH_BYTES = 8
++ IB_LRH_BYTES = 8,
++ IB_ETH_BYTES = 14,
++ IB_VLAN_BYTES = 4,
++ IB_GRH_BYTES = 40,
++ IB_IP4_BYTES = 20,
++ IB_UDP_BYTES = 8,
++ IB_BTH_BYTES = 12,
++ IB_DETH_BYTES = 8,
++ IB_EXT_ATOMICETH_BYTES = 28,
++ IB_EXT_XRC_BYTES = 4,
++ IB_ICRC_BYTES = 4
+ };
+
+ struct ib_field {
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Bart Van Assche <bart.vanassche@wdc.com>
+Date: Wed, 11 Oct 2017 10:48:43 -0700
+Subject: IB/core: Fix endianness annotation in rdma_is_multicast_addr()
+
+From: Bart Van Assche <bart.vanassche@wdc.com>
+
+
+[ Upstream commit 1c3aea2bc8f0b2e5b57375ead40457ff75a3a2ec ]
+
+Since ipv4_addr is a big endian 32-bit number, annotate it as such.
+
+Fixes: commit be1d325a3358 ("IB/core: Set RoCEv2 MGID according to spec")
+Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
+Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/rdma/ib_addr.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/rdma/ib_addr.h
++++ b/include/rdma/ib_addr.h
+@@ -306,12 +306,12 @@ static inline void rdma_get_ll_mac(struc
+
+ static inline int rdma_is_multicast_addr(struct in6_addr *addr)
+ {
+- u32 ipv4_addr;
++ __be32 ipv4_addr;
+
+ if (addr->s6_addr[0] == 0xff)
+ return 1;
+
+- memcpy(&ipv4_addr, addr->s6_addr + 12, 4);
++ ipv4_addr = addr->s6_addr32[3];
+ return (ipv6_addr_v4mapped(addr) && ipv4_is_multicast(ipv4_addr));
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Parav Pandit <parav@mellanox.com>
+Date: Mon, 16 Oct 2017 08:45:15 +0300
+Subject: IB/core: Fix use workqueue without WQ_MEM_RECLAIM
+
+From: Parav Pandit <parav@mellanox.com>
+
+
+[ Upstream commit 39baf10310e6669564a485b55267fae70a4e44ae ]
+
+The IB/core provides address resolution service and invokes callback
+handler when address resolve request completes of requester in worker
+thread context.
+
+Such caller might allocate or free memory in callback handler
+depending on the completion status to make further progress or to
+terminate a connection. Most ULPs resolve route which involves
+allocating route entry and path record elements in callback event handler.
+
+It has been noticed that WQ_MEM_RECLAIM flag should not be used for
+workers that tend to allocate memory in this [1] thread discussion.
+
+In order to mitigate this situation, WQ_MEM_RECLAIM flag was dropped for
+other such WQs in this [2] patch.
+
+Similar problem might arise with address resolution path, though its not
+yet noticed. The ib_addr workqueue is not memory reclaim path due to its
+nature of invoking callback that might allocate memory or don't free any
+memory under memory pressure.
+
+[1] https://www.spinics.net/lists/linux-rdma/msg53239.html
+[2] https://www.spinics.net/lists/linux-rdma/msg53416.html
+
+Fixes: f54816261c2b ("IB/addr: Remove deprecated create_singlethread_workqueue")
+Fixes: 5fff41e1f89d ("IB/core: Fix race condition in resolving IP to MAC")
+Signed-off-by: Parav Pandit <parav@mellanox.com>
+Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/addr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/core/addr.c
++++ b/drivers/infiniband/core/addr.c
+@@ -852,7 +852,7 @@ static struct notifier_block nb = {
+
+ int addr_init(void)
+ {
+- addr_wq = alloc_ordered_workqueue("ib_addr", WQ_MEM_RECLAIM);
++ addr_wq = alloc_ordered_workqueue("ib_addr", 0);
+ if (!addr_wq)
+ return -ENOMEM;
+
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Don Hiatt <don.hiatt@intel.com>
+Date: Mon, 9 Oct 2017 12:38:12 -0700
+Subject: IB/hfi1: Mask out A bit from psn trace
+
+From: Don Hiatt <don.hiatt@intel.com>
+
+
+[ Upstream commit d0a2f454713a42447ee4007582c0e43c47bcf230 ]
+
+The trace logic prior to the fixes below used to mask the
+A bit from the psn. It now mistakenly displays the A bit,
+which is already displayed separately.
+
+Fix by adding the appropriate mask to the psn tracing.
+
+Fixes: 228d2af1b723 ("IB/hfi1: Separate input/output header tracing")
+Fixes: 863cf89d472f ("IB/hfi1: Add 16B trace support")
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: Don Hiatt <don.hiatt@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/hfi1/trace.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/hw/hfi1/trace.c
++++ b/drivers/infiniband/hw/hfi1/trace.c
+@@ -154,7 +154,7 @@ void hfi1_trace_parse_9b_bth(struct ib_o
+ *opcode = ib_bth_get_opcode(ohdr);
+ *tver = ib_bth_get_tver(ohdr);
+ *pkey = ib_bth_get_pkey(ohdr);
+- *psn = ib_bth_get_psn(ohdr);
++ *psn = mask_psn(ib_bth_get_psn(ohdr));
+ *qpn = ib_bth_get_qpn(ohdr);
+ }
+
+@@ -169,7 +169,7 @@ void hfi1_trace_parse_16b_bth(struct ib_
+ *pad = ib_bth_get_pad(ohdr);
+ *se = ib_bth_get_se(ohdr);
+ *tver = ib_bth_get_tver(ohdr);
+- *psn = ib_bth_get_psn(ohdr);
++ *psn = mask_psn(ib_bth_get_psn(ohdr));
+ *qpn = ib_bth_get_qpn(ohdr);
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Patel Jay P <jay.p.patel@intel.com>
+Date: Mon, 23 Oct 2017 06:05:53 -0700
+Subject: Ib/hfi1: Return actual operational VLs in port info query
+
+From: Patel Jay P <jay.p.patel@intel.com>
+
+
+[ Upstream commit 00f9203119dd2774564407c7a67b17d81916298b ]
+
+__subn_get_opa_portinfo stores value returned by hfi1_get_ib_cfg() as
+operational vls. hfi1_get_ib_cfg() returns vls_operational field in
+hfi1_pportdata. The problem with this is that the value is always equal
+to vls_supported field in hfi1_pportdata.
+
+The logic to calculate operational_vls is to set value passed by FM
+(in __subn_set_opa_portinfo routine). If no value is passed then
+default value is stored in operational_vls.
+
+Field actual_vls_operational is calculated on the basis of buffer
+control table. Hence, modifying hfi1_get_ib_cfg() to return
+actual_operational_vls when used with HFI1_IB_CFG_OP_VLS parameter
+
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Patel Jay P <jay.p.patel@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/hfi1/chip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/hfi1/chip.c
++++ b/drivers/infiniband/hw/hfi1/chip.c
+@@ -9952,7 +9952,7 @@ int hfi1_get_ib_cfg(struct hfi1_pportdat
+ goto unimplemented;
+
+ case HFI1_IB_CFG_OP_VLS:
+- val = ppd->vls_operational;
++ val = ppd->actual_vls_operational;
+ break;
+ case HFI1_IB_CFG_VL_HIGH_CAP: /* VL arb high priority table size */
+ val = VL_ARB_HIGH_PRIO_TABLE_SIZE;
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Alex Vesker <valex@mellanox.com>
+Date: Tue, 10 Oct 2017 10:36:41 +0300
+Subject: IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop
+
+From: Alex Vesker <valex@mellanox.com>
+
+
+[ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ]
+
+When ndo_open and ndo_stop are called RTNL lock should be held.
+In this specific case ipoib_ib_dev_open calls the offloaded ndo_open
+which re-sets the number of TX queue assuming RTNL lock is held.
+Since RTNL lock is not held, RTNL assert will fail.
+
+Signed-off-by: Alex Vesker <valex@mellanox.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
++++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+@@ -1203,10 +1203,15 @@ static void __ipoib_ib_dev_flush(struct
+ ipoib_ib_dev_down(dev);
+
+ if (level == IPOIB_FLUSH_HEAVY) {
++ rtnl_lock();
+ if (test_bit(IPOIB_FLAG_INITIALIZED, &priv->flags))
+ ipoib_ib_dev_stop(dev);
+- if (ipoib_ib_dev_open(dev) != 0)
++
++ result = ipoib_ib_dev_open(dev);
++ rtnl_unlock();
++ if (result)
+ return;
++
+ if (netif_queue_stopped(dev))
+ netif_start_queue(dev);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Guy Levi <guyle@mellanox.com>
+Date: Wed, 25 Oct 2017 22:39:35 +0300
+Subject: IB/mlx4: Fix RSS's QPC attributes assignments
+
+From: Guy Levi <guyle@mellanox.com>
+
+
+[ Upstream commit 108809a0571cd1e1b317c5c083a371e163e1f8f9 ]
+
+In the modify QP handler the base_qpn_udp field in the RSS QPC is
+overwrite later by irrelevant value assignment. Hence, ingress packets
+which gets to the RSS QP will be steered then to a garbage QPN.
+
+The patch fixes this by skipping the above assignment when a RSS QP is
+modified, also, the RSS context's attributes assignments are relocated
+just before the context is posted to avoid future issues like this.
+
+Additionally, this patch takes the opportunity to change the code to be
+disciplined to the device's manual and assigns the RSS QP context just at
+RESET to INIT transition.
+
+Fixes:3078f5f1bd8b ("IB/mlx4: Add support for RSS QP")
+Signed-off-by: Guy Levi <guyle@mellanox.com>
+Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mlx4/qp.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/infiniband/hw/mlx4/qp.c
++++ b/drivers/infiniband/hw/mlx4/qp.c
+@@ -2182,11 +2182,6 @@ static int __mlx4_ib_modify_qp(void *src
+ context->flags = cpu_to_be32((to_mlx4_state(new_state) << 28) |
+ (to_mlx4_st(dev, qp->mlx4_ib_qp_type) << 16));
+
+- if (rwq_ind_tbl) {
+- fill_qp_rss_context(context, qp);
+- context->flags |= cpu_to_be32(1 << MLX4_RSS_QPC_FLAG_OFFSET);
+- }
+-
+ if (!(attr_mask & IB_QP_PATH_MIG_STATE))
+ context->flags |= cpu_to_be32(MLX4_QP_PM_MIGRATED << 11);
+ else {
+@@ -2387,6 +2382,7 @@ static int __mlx4_ib_modify_qp(void *src
+ context->pd = cpu_to_be32(pd->pdn);
+
+ if (!rwq_ind_tbl) {
++ context->params1 = cpu_to_be32(MLX4_IB_ACK_REQ_FREQ << 28);
+ get_cqs(qp, src_type, &send_cq, &recv_cq);
+ } else { /* Set dummy CQs to be compatible with HV and PRM */
+ send_cq = to_mcq(rwq_ind_tbl->ind_tbl[0]->cq);
+@@ -2394,7 +2390,6 @@ static int __mlx4_ib_modify_qp(void *src
+ }
+ context->cqn_send = cpu_to_be32(send_cq->mcq.cqn);
+ context->cqn_recv = cpu_to_be32(recv_cq->mcq.cqn);
+- context->params1 = cpu_to_be32(MLX4_IB_ACK_REQ_FREQ << 28);
+
+ /* Set "fast registration enabled" for all kernel QPs */
+ if (!ibuobject)
+@@ -2513,7 +2508,7 @@ static int __mlx4_ib_modify_qp(void *src
+ MLX4_IB_LINK_TYPE_ETH;
+ if (dev->dev->caps.tunnel_offload_mode == MLX4_TUNNEL_OFFLOAD_MODE_VXLAN) {
+ /* set QP to receive both tunneled & non-tunneled packets */
+- if (!(context->flags & cpu_to_be32(1 << MLX4_RSS_QPC_FLAG_OFFSET)))
++ if (!rwq_ind_tbl)
+ context->srqn = cpu_to_be32(7 << 28);
+ }
+ }
+@@ -2562,6 +2557,13 @@ static int __mlx4_ib_modify_qp(void *src
+ }
+ }
+
++ if (rwq_ind_tbl &&
++ cur_state == IB_QPS_RESET &&
++ new_state == IB_QPS_INIT) {
++ fill_qp_rss_context(context, qp);
++ context->flags |= cpu_to_be32(1 << MLX4_RSS_QPC_FLAG_OFFSET);
++ }
++
+ err = mlx4_qp_modify(dev->dev, &qp->mtt, to_mlx4_state(cur_state),
+ to_mlx4_state(new_state), context, optpar,
+ sqd_event, &qp->mqp);
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Matteo Croce <mcroce@redhat.com>
+Date: Thu, 12 Oct 2017 16:12:37 +0200
+Subject: icmp: don't fail on fragment reassembly time exceeded
+
+From: Matteo Croce <mcroce@redhat.com>
+
+
+[ Upstream commit 258bbb1b0e594ad5f5652cb526b3c63e6a7fad3d ]
+
+The ICMP implementation currently replies to an ICMP time exceeded message
+(type 11) with an ICMP host unreachable message (type 3, code 1).
+
+However, time exceeded messages can either represent "time to live exceeded
+in transit" (code 0) or "fragment reassembly time exceeded" (code 1).
+
+Unconditionally replying to "fragment reassembly time exceeded" with
+host unreachable messages might cause unjustified connection resets
+which are now easily triggered as UFO has been removed, because, in turn,
+sending large buffers triggers IP fragmentation.
+
+The issue can be easily reproduced by running a lot of UDP streams
+which is likely to trigger IP fragmentation:
+
+ # start netserver in the test namespace
+ ip netns add test
+ ip netns exec test netserver
+
+ # create a VETH pair
+ ip link add name veth0 type veth peer name veth0 netns test
+ ip link set veth0 up
+ ip -n test link set veth0 up
+
+ for i in $(seq 20 29); do
+ # assign addresses to both ends
+ ip addr add dev veth0 192.168.$i.1/24
+ ip -n test addr add dev veth0 192.168.$i.2/24
+
+ # start the traffic
+ netperf -L 192.168.$i.1 -H 192.168.$i.2 -t UDP_STREAM -l 0 &
+ done
+
+ # wait
+ send_data: data send error: No route to host (errno 113)
+ netperf: send_omni: send_data failed: No route to host
+
+We need to differentiate instead: if fragment reassembly time exceeded
+is reported, we need to silently drop the packet,
+if time to live exceeded is reported, maintain the current behaviour.
+In both cases increment the related error count "icmpInTimeExcds".
+
+While at it, fix a typo in a comment, and convert the if statement
+into a switch to mate it more readable.
+
+Signed-off-by: Matteo Croce <mcroce@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/icmp.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+--- a/net/ipv4/icmp.c
++++ b/net/ipv4/icmp.c
+@@ -782,7 +782,7 @@ static bool icmp_tag_validation(int prot
+ }
+
+ /*
+- * Handle ICMP_DEST_UNREACH, ICMP_TIME_EXCEED, ICMP_QUENCH, and
++ * Handle ICMP_DEST_UNREACH, ICMP_TIME_EXCEEDED, ICMP_QUENCH, and
+ * ICMP_PARAMETERPROB.
+ */
+
+@@ -810,7 +810,8 @@ static bool icmp_unreach(struct sk_buff
+ if (iph->ihl < 5) /* Mangled header, drop. */
+ goto out_err;
+
+- if (icmph->type == ICMP_DEST_UNREACH) {
++ switch (icmph->type) {
++ case ICMP_DEST_UNREACH:
+ switch (icmph->code & 15) {
+ case ICMP_NET_UNREACH:
+ case ICMP_HOST_UNREACH:
+@@ -846,8 +847,16 @@ static bool icmp_unreach(struct sk_buff
+ }
+ if (icmph->code > NR_ICMP_UNREACH)
+ goto out;
+- } else if (icmph->type == ICMP_PARAMETERPROB)
++ break;
++ case ICMP_PARAMETERPROB:
+ info = ntohl(icmph->un.gateway) >> 24;
++ break;
++ case ICMP_TIME_EXCEEDED:
++ __ICMP_INC_STATS(net, ICMP_MIB_INTIMEEXCDS);
++ if (icmph->code == ICMP_EXC_FRAGTIME)
++ goto out;
++ break;
++ }
+
+ /*
+ * Throw it at our lower layers
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Gary R Hook <gary.hook@amd.com>
+Date: Fri, 3 Nov 2017 10:50:34 -0600
+Subject: iommu/amd: Limit the IOVA page range to the specified addresses
+
+From: Gary R Hook <gary.hook@amd.com>
+
+
+[ Upstream commit b92b4fb5c14257c0e7eae291ecc1f7b1962e1699 ]
+
+The extent of pages specified when applying a reserved region should
+include up to the last page of the range, but not the page following
+the range.
+
+Signed-off-by: Gary R Hook <gary.hook@amd.com>
+Fixes: 8d54d6c8b8f3 ('iommu/amd: Implement apply_dm_region call-back')
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -3155,7 +3155,7 @@ static void amd_iommu_apply_resv_region(
+ unsigned long start, end;
+
+ start = IOVA_PFN(region->start);
+- end = IOVA_PFN(region->start + region->length);
++ end = IOVA_PFN(region->start + region->length - 1);
+
+ WARN_ON_ONCE(reserve_iova(&dma_dom->iovad, start, end) == NULL);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Matthias Brugger <matthias.bgg@gmail.com>
+Date: Mon, 30 Oct 2017 12:37:55 +0100
+Subject: iommu/mediatek: Fix driver name
+
+From: Matthias Brugger <matthias.bgg@gmail.com>
+
+
+[ Upstream commit 395df08d2e1de238a9c8c33fdcd0e2160efd63a9 ]
+
+There exist two Mediatek iommu drivers for the two different
+generations of the device. But both drivers have the same name
+"mtk-iommu". This breaks the registration of the second driver:
+
+Error: Driver 'mtk-iommu' is already registered, aborting...
+
+Fix this by changing the name for first generation to
+"mtk-iommu-v1".
+
+Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW")
+Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/mtk_iommu_v1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/mtk_iommu_v1.c
++++ b/drivers/iommu/mtk_iommu_v1.c
+@@ -708,7 +708,7 @@ static struct platform_driver mtk_iommu_
+ .probe = mtk_iommu_probe,
+ .remove = mtk_iommu_remove,
+ .driver = {
+- .name = "mtk-iommu",
++ .name = "mtk-iommu-v1",
+ .of_match_table = mtk_iommu_of_ids,
+ .pm = &mtk_iommu_pm_ops,
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Colin Ian King <colin.king@canonical.com>
+Date: Tue, 17 Oct 2017 16:54:52 +0100
+Subject: ipmi_si: fix memory leak on new_smi
+
+From: Colin Ian King <colin.king@canonical.com>
+
+
+[ Upstream commit c0a32fe13cd323ca9420500b16fd69589c9ba91e ]
+
+The error exit path omits kfree'ing the allocated new_smi, causing a memory
+leak. Fix this by kfree'ing new_smi.
+
+Detected by CoverityScan, CID#14582571 ("Resource Leak")
+
+Fixes: 7e030d6dff71 ("ipmi: Prefer ACPI system interfaces over SMBIOS ones")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/ipmi/ipmi_si_intf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/char/ipmi/ipmi_si_intf.c
++++ b/drivers/char/ipmi/ipmi_si_intf.c
+@@ -3469,6 +3469,7 @@ static int add_smi(struct smi_info *new_
+ ipmi_addr_src_to_str(new_smi->addr_source),
+ si_to_str[new_smi->si_type]);
+ rv = -EBUSY;
++ kfree(new_smi);
+ goto out_err;
+ }
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Eric Dumazet <edumazet@google.com>
+Date: Wed, 18 Oct 2017 17:02:03 -0700
+Subject: ipv4: ipv4_default_advmss() should use route mtu
+
+From: Eric Dumazet <edumazet@google.com>
+
+
+[ Upstream commit 164a5e7ad531e181334a3d3f03d0d5ad20d6faea ]
+
+ipv4_default_advmss() incorrectly uses the device MTU instead
+of the route provided one. IPv6 has the proper behavior,
+lets harmonize the two protocols.
+
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/route.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ipv4/route.c
++++ b/net/ipv4/route.c
+@@ -1254,7 +1254,7 @@ static void set_class_tag(struct rtable
+ static unsigned int ipv4_default_advmss(const struct dst_entry *dst)
+ {
+ unsigned int header_size = sizeof(struct tcphdr) + sizeof(struct iphdr);
+- unsigned int advmss = max_t(unsigned int, dst->dev->mtu - header_size,
++ unsigned int advmss = max_t(unsigned int, ipv4_mtu(dst) - header_size,
+ ip_rt_min_advmss);
+
+ return min(advmss, IPV4_MAX_PMTU - header_size);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: tangwenji <tang.wenji@zte.com.cn>
+Date: Fri, 15 Sep 2017 16:03:13 +0800
+Subject: iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
+
+From: tangwenji <tang.wenji@zte.com.cn>
+
+
+[ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ]
+
+tpg must free when call core_tpg_register() return fail
+
+Signed-off-by: tangwenji <tang.wenji@zte.com.cn>
+Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/target/iscsi/iscsi_target_configfs.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/target/iscsi/iscsi_target_configfs.c
++++ b/drivers/target/iscsi/iscsi_target_configfs.c
+@@ -1123,7 +1123,7 @@ static struct se_portal_group *lio_targe
+
+ ret = core_tpg_register(wwn, &tpg->tpg_se_tpg, SCSI_PROTOCOL_ISCSI);
+ if (ret < 0)
+- return NULL;
++ goto free_out;
+
+ ret = iscsit_tpg_add_portal_group(tiqn, tpg);
+ if (ret != 0)
+@@ -1135,6 +1135,7 @@ static struct se_portal_group *lio_targe
+ return &tpg->tpg_se_tpg;
+ out:
+ core_tpg_deregister(&tpg->tpg_se_tpg);
++free_out:
+ kfree(tpg);
+ return NULL;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Wanpeng Li <wanpeng.li@hotmail.com>
+Date: Thu, 19 Oct 2017 07:00:34 +0800
+Subject: KVM: nVMX: Fix EPT switching advertising
+
+From: Wanpeng Li <wanpeng.li@hotmail.com>
+
+
+[ Upstream commit 575b3a2cb439b03fd603ea77c73c76f3ed237596 ]
+
+I can use vmxcap tool to observe "EPTP Switching yes" even if EPT is not
+exposed to L1.
+
+EPT switching is advertised unconditionally since it is emulated, however,
+it can be treated as an extended feature for EPT and it should not be
+advertised if EPT itself is not exposed. This patch fixes it.
+
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Cc: Jim Mattson <jmattson@google.com>
+Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -2845,8 +2845,9 @@ static void nested_vmx_setup_ctls_msrs(s
+ * Advertise EPTP switching unconditionally
+ * since we emulate it
+ */
+- vmx->nested.nested_vmx_vmfunc_controls =
+- VMX_VMFUNC_EPTP_SWITCHING;
++ if (enable_ept)
++ vmx->nested.nested_vmx_vmfunc_controls =
++ VMX_VMFUNC_EPTP_SWITCHING;
+ }
+
+ /*
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Wed, 25 Oct 2017 15:57:55 +0200
+Subject: l2tp: cleanup l2tp_tunnel_delete calls
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+
+[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]
+
+l2tp_tunnel_delete does not return anything since commit 62b982eeb458
+("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of
+l2tp_tunnel_delete still do casts to void to avoid unused return value
+warnings.
+
+Kill these now useless casts.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Cc: Sabrina Dubroca <sd@queasysnail.net>
+Cc: Guillaume Nault <g.nault@alphalink.fr>
+Cc: David S. Miller <davem@davemloft.net>
+Cc: netdev@vger.kernel.org
+Acked-by: Guillaume Nault <g.nault@alphalink.fr>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/l2tp/l2tp_core.c | 2 +-
+ net/l2tp/l2tp_netlink.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/l2tp/l2tp_core.c
++++ b/net/l2tp/l2tp_core.c
+@@ -1891,7 +1891,7 @@ static __net_exit void l2tp_exit_net(str
+
+ rcu_read_lock_bh();
+ list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
+- (void)l2tp_tunnel_delete(tunnel);
++ l2tp_tunnel_delete(tunnel);
+ }
+ rcu_read_unlock_bh();
+
+--- a/net/l2tp/l2tp_netlink.c
++++ b/net/l2tp/l2tp_netlink.c
+@@ -282,7 +282,7 @@ static int l2tp_nl_cmd_tunnel_delete(str
+ l2tp_tunnel_notify(&l2tp_nl_family, info,
+ tunnel, L2TP_CMD_TUNNEL_DELETE);
+
+- (void) l2tp_tunnel_delete(tunnel);
++ l2tp_tunnel_delete(tunnel);
+
+ l2tp_tunnel_dec_refcount(tunnel);
+
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Rakesh Pandit <rakesh@tuxera.com>
+Date: Fri, 13 Oct 2017 14:46:28 +0200
+Subject: lightnvm: pblk: fix changing GC group list for a line
+
+From: Rakesh Pandit <rakesh@tuxera.com>
+
+
+[ Upstream commit 27b978725d895e704aab44b99242a0514485d798 ]
+
+pblk_line_gc_list seems to had a bug since the introduction of pblk in
+getting GC list for a line. In b20ba1bc7 while redesigning the GC
+algorithm, the naming for the GC thresholds was altered, but the
+values for high_thrs and mid_thrs were not. The result is that when
+moving to the GC lists, the mid threshold is never evaluated.
+
+Fixes: a4bd217b4("lightnvm: physical block device (pblk) target")
+Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
+Signed-off-by: Matias Bjørling <m@bjorling.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/lightnvm/pblk-init.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/lightnvm/pblk-init.c
++++ b/drivers/lightnvm/pblk-init.c
+@@ -681,8 +681,8 @@ static int pblk_lines_init(struct pblk *
+ lm->blk_bitmap_len = BITS_TO_LONGS(geo->nr_luns) * sizeof(long);
+ lm->sec_bitmap_len = BITS_TO_LONGS(lm->sec_per_line) * sizeof(long);
+ lm->lun_bitmap_len = BITS_TO_LONGS(geo->nr_luns) * sizeof(long);
+- lm->high_thrs = lm->sec_per_line / 2;
+- lm->mid_thrs = lm->sec_per_line / 4;
++ lm->mid_thrs = lm->sec_per_line / 2;
++ lm->high_thrs = lm->sec_per_line / 4;
+ lm->meta_distance = (geo->nr_luns / 2) * pblk->min_write_pgs;
+
+ /* Calculate necessary pages for smeta. See comment over struct
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Javier González <javier@cnexlabs.com>
+Date: Fri, 13 Oct 2017 14:46:06 +0200
+Subject: lightnvm: pblk: fix min size for page mempool
+
+From: Javier González <javier@cnexlabs.com>
+
+
+[ Upstream commit bd432417681a224d9fa4a9d43be7d4edc82135b2 ]
+
+pblk uses an internal page mempool for allocating pages on internal
+bios. The main two users of this memory pool are partial reads (reads
+with some sectors in cache and some on media) and padded writes, which
+need to add dummy pages to an existing bio already containing valid
+data (and with a large enough bioset allocated). In both cases, the
+maximum number of pages per bio is defined by the maximum number of
+physical sectors supported by the underlying device.
+
+This patch fixes a bad mempool allocation, where the min_nr of elements
+on the pool was fixed (to 16), which is lower than the maximum number
+of sectors supported by NVMe (as of the time for this patch). Instead,
+use the maximum number of allowed sectors reported by the device.
+
+Reported-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Javier González <javier@cnexlabs.com>
+Signed-off-by: Matias Bjørling <m@bjorling.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/lightnvm/pblk-core.c | 6 +++---
+ drivers/lightnvm/pblk-init.c | 15 ++++++++-------
+ drivers/lightnvm/pblk-read.c | 2 +-
+ drivers/lightnvm/pblk.h | 2 +-
+ 4 files changed, 13 insertions(+), 12 deletions(-)
+
+--- a/drivers/lightnvm/pblk-core.c
++++ b/drivers/lightnvm/pblk-core.c
+@@ -193,7 +193,7 @@ void pblk_bio_free_pages(struct pblk *pb
+ bio_advance(bio, off * PBLK_EXPOSED_PAGE_SIZE);
+ for (i = off; i < nr_pages + off; i++) {
+ bv = bio->bi_io_vec[i];
+- mempool_free(bv.bv_page, pblk->page_pool);
++ mempool_free(bv.bv_page, pblk->page_bio_pool);
+ }
+ }
+
+@@ -205,14 +205,14 @@ int pblk_bio_add_pages(struct pblk *pblk
+ int i, ret;
+
+ for (i = 0; i < nr_pages; i++) {
+- page = mempool_alloc(pblk->page_pool, flags);
++ page = mempool_alloc(pblk->page_bio_pool, flags);
+ if (!page)
+ goto err;
+
+ ret = bio_add_pc_page(q, bio, page, PBLK_EXPOSED_PAGE_SIZE, 0);
+ if (ret != PBLK_EXPOSED_PAGE_SIZE) {
+ pr_err("pblk: could not add page to bio\n");
+- mempool_free(page, pblk->page_pool);
++ mempool_free(page, pblk->page_bio_pool);
+ goto err;
+ }
+ }
+--- a/drivers/lightnvm/pblk-init.c
++++ b/drivers/lightnvm/pblk-init.c
+@@ -132,7 +132,6 @@ static int pblk_rwb_init(struct pblk *pb
+ }
+
+ /* Minimum pages needed within a lun */
+-#define PAGE_POOL_SIZE 16
+ #define ADDR_POOL_SIZE 64
+
+ static int pblk_set_ppaf(struct pblk *pblk)
+@@ -247,14 +246,16 @@ static int pblk_core_init(struct pblk *p
+ if (pblk_init_global_caches(pblk))
+ return -ENOMEM;
+
+- pblk->page_pool = mempool_create_page_pool(PAGE_POOL_SIZE, 0);
+- if (!pblk->page_pool)
++ /* internal bios can be at most the sectors signaled by the device. */
++ pblk->page_bio_pool = mempool_create_page_pool(nvm_max_phys_sects(dev),
++ 0);
++ if (!pblk->page_bio_pool)
+ return -ENOMEM;
+
+ pblk->line_ws_pool = mempool_create_slab_pool(PBLK_WS_POOL_SIZE,
+ pblk_blk_ws_cache);
+ if (!pblk->line_ws_pool)
+- goto free_page_pool;
++ goto free_page_bio_pool;
+
+ pblk->rec_pool = mempool_create_slab_pool(geo->nr_luns, pblk_rec_cache);
+ if (!pblk->rec_pool)
+@@ -309,8 +310,8 @@ free_rec_pool:
+ mempool_destroy(pblk->rec_pool);
+ free_blk_ws_pool:
+ mempool_destroy(pblk->line_ws_pool);
+-free_page_pool:
+- mempool_destroy(pblk->page_pool);
++free_page_bio_pool:
++ mempool_destroy(pblk->page_bio_pool);
+ return -ENOMEM;
+ }
+
+@@ -322,7 +323,7 @@ static void pblk_core_free(struct pblk *
+ if (pblk->bb_wq)
+ destroy_workqueue(pblk->bb_wq);
+
+- mempool_destroy(pblk->page_pool);
++ mempool_destroy(pblk->page_bio_pool);
+ mempool_destroy(pblk->line_ws_pool);
+ mempool_destroy(pblk->rec_pool);
+ mempool_destroy(pblk->g_rq_pool);
+--- a/drivers/lightnvm/pblk-read.c
++++ b/drivers/lightnvm/pblk-read.c
+@@ -238,7 +238,7 @@ static int pblk_fill_partial_read_bio(st
+ kunmap_atomic(src_p);
+ kunmap_atomic(dst_p);
+
+- mempool_free(src_bv.bv_page, pblk->page_pool);
++ mempool_free(src_bv.bv_page, pblk->page_bio_pool);
+
+ hole = find_next_zero_bit(read_bitmap, nr_secs, hole + 1);
+ } while (hole < nr_secs);
+--- a/drivers/lightnvm/pblk.h
++++ b/drivers/lightnvm/pblk.h
+@@ -618,7 +618,7 @@ struct pblk {
+
+ struct list_head compl_list;
+
+- mempool_t *page_pool;
++ mempool_t *page_bio_pool;
+ mempool_t *line_ws_pool;
+ mempool_t *rec_pool;
+ mempool_t *g_rq_pool;
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Javier González <javier@cnexlabs.com>
+Date: Fri, 13 Oct 2017 14:46:01 +0200
+Subject: lightnvm: pblk: initialize debug stat counter
+
+From: Javier González <javier@cnexlabs.com>
+
+
+[ Upstream commit a1121176ff757e3c073490a69608ea0b18a00ec1 ]
+
+Initialize the stat counter for garbage collected reads.
+
+Fixes: a4bd217b43268 ("lightnvm: physical block device (pblk) target")
+Signed-off-by: Javier González <javier@cnexlabs.com>
+Signed-off-by: Matias Bjørling <m@bjorling.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/lightnvm/pblk-init.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/lightnvm/pblk-init.c
++++ b/drivers/lightnvm/pblk-init.c
+@@ -945,6 +945,7 @@ static void *pblk_init(struct nvm_tgt_de
+ atomic_long_set(&pblk->recov_writes, 0);
+ atomic_long_set(&pblk->recov_writes, 0);
+ atomic_long_set(&pblk->recov_gc_writes, 0);
++ atomic_long_set(&pblk->recov_gc_reads, 0);
+ #endif
+
+ atomic_long_set(&pblk->read_failed, 0);
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Hans Holmberg <hans.holmberg@cnexlabs.com>
+Date: Fri, 13 Oct 2017 14:46:34 +0200
+Subject: lightnvm: pblk: prevent gc kicks when gc is not operational
+
+From: Hans Holmberg <hans.holmberg@cnexlabs.com>
+
+
+[ Upstream commit 3e3a5b8ebd5d3b1d68facc58b0674a2564653222 ]
+
+GC can be kicked after it has been shut down when closing the last
+line during exit, resulting in accesses to freed structures.
+
+Make sure that GC is not triggered while it is not operational.
+Also make sure that GC won't be re-activated during exit when
+running on another processor by using timer_del_sync.
+
+Signed-off-by: Hans Holmberg <hans.holmberg@cnexlabs.com>
+Signed-off-by: Matias Bjørling <m@bjorling.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/lightnvm/pblk-gc.c | 9 +++++----
+ drivers/lightnvm/pblk-init.c | 1 +
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/lightnvm/pblk-gc.c
++++ b/drivers/lightnvm/pblk-gc.c
+@@ -486,10 +486,10 @@ void pblk_gc_should_start(struct pblk *p
+ {
+ struct pblk_gc *gc = &pblk->gc;
+
+- if (gc->gc_enabled && !gc->gc_active)
++ if (gc->gc_enabled && !gc->gc_active) {
+ pblk_gc_start(pblk);
+-
+- pblk_gc_kick(pblk);
++ pblk_gc_kick(pblk);
++ }
+ }
+
+ /*
+@@ -628,7 +628,8 @@ void pblk_gc_exit(struct pblk *pblk)
+ flush_workqueue(gc->gc_reader_wq);
+ flush_workqueue(gc->gc_line_reader_wq);
+
+- del_timer(&gc->gc_timer);
++ gc->gc_enabled = 0;
++ del_timer_sync(&gc->gc_timer);
+ pblk_gc_stop(pblk, 1);
+
+ if (gc->gc_ts)
+--- a/drivers/lightnvm/pblk-init.c
++++ b/drivers/lightnvm/pblk-init.c
+@@ -923,6 +923,7 @@ static void *pblk_init(struct nvm_tgt_de
+ pblk->dev = dev;
+ pblk->disk = tdisk;
+ pblk->state = PBLK_STATE_RUNNING;
++ pblk->gc.gc_enabled = 0;
+
+ spin_lock_init(&pblk->trans_lock);
+ spin_lock_init(&pblk->lock);
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Rakesh Pandit <rakesh@tuxera.com>
+Date: Fri, 13 Oct 2017 14:45:56 +0200
+Subject: lightnvm: pblk: protect line bitmap while submitting meta io
+
+From: Rakesh Pandit <rakesh@tuxera.com>
+
+
+[ Upstream commit e57903fd972a398b7140d0bc055714e13a0e58c5 ]
+
+It seems pblk_dealloc_page would race against pblk_alloc_pages for
+line bitmap for sector allocation.The chances are very low but might
+as well protect the bitmap properly.
+
+Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
+Reviewed-by: Javier González <javier@cnexlabs.com>
+Signed-off-by: Matias Bjørling <m@bjorling.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/lightnvm/pblk-core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/lightnvm/pblk-core.c
++++ b/drivers/lightnvm/pblk-core.c
+@@ -486,12 +486,14 @@ void pblk_dealloc_page(struct pblk *pblk
+ u64 addr;
+ int i;
+
++ spin_lock(&line->lock);
+ addr = find_next_zero_bit(line->map_bitmap,
+ pblk->lm.sec_per_line, line->cur_sec);
+ line->cur_sec = addr - nr_secs;
+
+ for (i = 0; i < nr_secs; i++, line->cur_sec--)
+ WARN_ON(!test_and_clear_bit(line->cur_sec, line->map_bitmap));
++ spin_unlock(&line->lock);
+ }
+
+ u64 __pblk_alloc_page(struct pblk *pblk, struct pblk_line *line, int nr_secs)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Javier González <javier@cnexlabs.com>
+Date: Fri, 13 Oct 2017 14:46:02 +0200
+Subject: lightnvm: pblk: use right flag for GC allocation
+
+From: Javier González <javier@cnexlabs.com>
+
+
+[ Upstream commit 7d327a9ed6c4dca341ebf99012e0a6b80a3050e6 ]
+
+The data buffer for the GC path allocates virtual memory through
+vmalloc. When this change was introduced, a flag signaling kmalloc'ed
+memory was wrongly introduced. Use the right flag when creating a bio
+from this buffer.
+
+Fixes: de54e703a422 ("lightnvm: pblk: use vmalloc for GC data buffer")
+Signed-off-by: Javier González <javier@cnexlabs.com>
+Signed-off-by: Matias Bjørling <m@bjorling.me>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/lightnvm/pblk-read.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/lightnvm/pblk-read.c
++++ b/drivers/lightnvm/pblk-read.c
+@@ -499,7 +499,7 @@ int pblk_submit_read_gc(struct pblk *pbl
+
+ data_len = (*secs_to_gc) * geo->sec_size;
+ bio = pblk_bio_map_addr(pblk, data, *secs_to_gc, data_len,
+- PBLK_KMALLOC_META, GFP_KERNEL);
++ PBLK_VMALLOC_META, GFP_KERNEL);
+ if (IS_ERR(bio)) {
+ pr_err("pblk: could not allocate GC bio (%lu)\n", PTR_ERR(bio));
+ goto err_free_dma;
+@@ -519,7 +519,7 @@ int pblk_submit_read_gc(struct pblk *pbl
+ if (ret) {
+ bio_endio(bio);
+ pr_err("pblk: GC read request failed\n");
+- goto err_free_dma;
++ goto err_free_bio;
+ }
+
+ if (!wait_for_completion_io_timeout(&wait,
+@@ -541,10 +541,13 @@ int pblk_submit_read_gc(struct pblk *pbl
+ atomic_long_sub(*secs_to_gc, &pblk->inflight_reads);
+ #endif
+
++ bio_put(bio);
+ out:
+ nvm_dev_dma_free(dev->parent, rqd.meta_list, rqd.dma_meta_list);
+ return NVM_IO_OK;
+
++err_free_bio:
++ bio_put(bio);
+ err_free_dma:
+ nvm_dev_dma_free(dev->parent, rqd.meta_list, rqd.dma_meta_list);
+ return NVM_IO_ERR;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Felix Manlunas <felix.manlunas@cavium.com>
+Date: Thu, 26 Oct 2017 16:46:36 -0700
+Subject: liquidio: fix kernel panic in VF driver
+
+From: Felix Manlunas <felix.manlunas@cavium.com>
+
+
+[ Upstream commit aa28667cfbe4ff6f14454dda210b1f2e485f99b5 ]
+
+Doing ifconfig down on VF driver in the middle of receiving line rate
+traffic causes a kernel panic:
+
+ LiquidIO_VF 0000:02:00.3: should not come here should not get rx when poll mode = 0 for vf
+ BUG: unable to handle kernel NULL pointer dereference at (null)
+ .
+ .
+ .
+ Call Trace:
+ <IRQ>
+ ? tasklet_action+0x102/0x120
+ __do_softirq+0x91/0x292
+ irq_exit+0xb6/0xc0
+ do_IRQ+0x4f/0xd0
+ common_interrupt+0x93/0x93
+ </IRQ>
+ RIP: 0010:cpuidle_enter_state+0x142/0x2f0
+ RSP: 0018:ffffffffa6403e20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff59
+ RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000001f
+ RDX: 0000000000000000 RSI: 000000002ab7519f RDI: 0000000000000000
+ RBP: ffffffffa6403e58 R08: 0000000000000084 R09: 0000000000000018
+ R10: ffffffffa6403df0 R11: 00000000000003c7 R12: 0000000000000003
+ R13: ffffd27ebd806800 R14: ffffffffa64d40d8 R15: 0000007be072823f
+ cpuidle_enter+0x17/0x20
+ call_cpuidle+0x23/0x40
+ do_idle+0x18c/0x1f0
+ cpu_startup_entry+0x64/0x70
+ rest_init+0xa5/0xb0
+ start_kernel+0x45e/0x46b
+ x86_64_start_reservations+0x24/0x26
+ x86_64_start_kernel+0x6f/0x72
+ secondary_startup_64+0xa5/0xa5
+ Code: Bad RIP value.
+ RIP: (null) RSP: ffff9246ed003f28
+ CR2: 0000000000000000
+ ---[ end trace 92731e80f31b7d7d ]---
+ Kernel panic - not syncing: Fatal exception in interrupt
+ Kernel Offset: 0x24000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+ ---[ end Kernel panic - not syncing: Fatal exception in interrupt
+
+Reason is: in the function assigned to net_device_ops->ndo_stop, the steps
+for bringing down the interface are done in the wrong order. The step that
+notifies the NIC firmware to stop forwarding packets to host is done too
+late. Fix it by moving that step to the beginning.
+
+Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
+Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
++++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
+@@ -1289,6 +1289,9 @@ static int liquidio_stop(struct net_devi
+ struct octeon_device *oct = lio->oct_dev;
+ struct napi_struct *napi, *n;
+
++ /* tell Octeon to stop forwarding packets to host */
++ send_rx_ctrl_cmd(lio, 0);
++
+ if (oct->props[lio->ifidx].napi_enabled) {
+ list_for_each_entry_safe(napi, n, &netdev->napi_list, dev_list)
+ napi_disable(napi);
+@@ -1306,9 +1309,6 @@ static int liquidio_stop(struct net_devi
+ netif_carrier_off(netdev);
+ lio->link_changes++;
+
+- /* tell Octeon to stop forwarding packets to host */
+- send_rx_ctrl_cmd(lio, 0);
+-
+ ifstate_reset(lio, LIO_IFSTATE_RUNNING);
+
+ txqs_stop(netdev);
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Alexander Duyck <alexander.h.duyck@intel.com>
+Date: Fri, 13 Oct 2017 13:40:24 -0700
+Subject: macvlan: Only deliver one copy of the frame to the macvlan interface
+
+From: Alexander Duyck <alexander.h.duyck@intel.com>
+
+
+[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]
+
+This patch intoduces a slight adjustment for macvlan to address the fact
+that in source mode I was seeing two copies of any packet addressed to the
+macvlan interface being delivered where there should have been only one.
+
+The issue appears to be that one copy was delivered based on the source MAC
+address and then the second copy was being delivered based on the
+destination MAC address. To fix it I am just treating a unicast address
+match as though it is not a match since source based macvlan isn't supposed
+to be matching based on the destination MAC anyway.
+
+Fixes: 79cf79abce71 ("macvlan: add source mode")
+Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/macvlan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/macvlan.c
++++ b/drivers/net/macvlan.c
+@@ -480,7 +480,7 @@ static rx_handler_result_t macvlan_handl
+ struct macvlan_dev, list);
+ else
+ vlan = macvlan_hash_lookup(port, eth->h_dest);
+- if (vlan == NULL)
++ if (!vlan || vlan->mode == MACVLAN_MODE_SOURCE)
+ return RX_HANDLER_PASS;
+
+ dev = vlan->dev;
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Guoqing Jiang <gqjiang@suse.com>
+Date: Fri, 29 Sep 2017 09:16:43 +0800
+Subject: md-cluster: fix wrong condition check in raid1_write_request
+
+From: Guoqing Jiang <gqjiang@suse.com>
+
+
+[ Upstream commit 385f4d7f946b08f36f68b0a28e95a319925b6b62 ]
+
+The check used here is to avoid conflict between write and
+resync, however we used the wrong logic, it should be the
+inverse of the checking inside "if".
+
+Fixes: 589a1c4 ("Suspend writes in RAID1 if within range")
+Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid1.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -1309,12 +1309,12 @@ static void raid1_write_request(struct m
+ sigset_t full, old;
+ prepare_to_wait(&conf->wait_barrier,
+ &w, TASK_INTERRUPTIBLE);
+- if (bio_end_sector(bio) <= mddev->suspend_lo ||
+- bio->bi_iter.bi_sector >= mddev->suspend_hi ||
+- (mddev_is_clustered(mddev) &&
++ if ((bio_end_sector(bio) <= mddev->suspend_lo ||
++ bio->bi_iter.bi_sector >= mddev->suspend_hi) &&
++ (!mddev_is_clustered(mddev) ||
+ !md_cluster_ops->area_resyncing(mddev, WRITE,
+- bio->bi_iter.bi_sector,
+- bio_end_sector(bio))))
++ bio->bi_iter.bi_sector,
++ bio_end_sector(bio))))
+ break;
+ sigfillset(&full);
+ sigprocmask(SIG_BLOCK, &full, &old);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Date: Wed, 1 Nov 2017 08:09:59 -0400
+Subject: media: camss-vfe: always initialize reg at vfe_set_xbar_cfg()
+
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+
+
+[ Upstream commit 9917fbcfa20ab987d6381fd0365665e5c1402d75 ]
+
+if output->wm_num is bigger than 2, the value for reg is
+not initialized, as warned by smatch:
+ drivers/media/platform/qcom/camss-8x16/camss-vfe.c:633 vfe_set_xbar_cfg() error: uninitialized symbol 'reg'.
+ drivers/media/platform/qcom/camss-8x16/camss-vfe.c:637 vfe_set_xbar_cfg() error: uninitialized symbol 'reg'.
+
+That shouldn't happen in practice, so add a logic that will
+break the loop if i > 1, fixing the warnings.
+
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Acked-by: Todor Tomov <todor.tomov@linaro.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
++++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
+@@ -622,6 +622,9 @@ static void vfe_set_xbar_cfg(struct vfe_
+ reg = VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN;
+ if (p == V4L2_PIX_FMT_NV12 || p == V4L2_PIX_FMT_NV16)
+ reg |= VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA;
++ } else {
++ /* On current devices output->wm_num is always <= 2 */
++ break;
+ }
+
+ if (output->wm_idx[i] % 2 == 1)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Adam Sampson <ats@offog.org>
+Date: Tue, 24 Oct 2017 16:14:46 -0400
+Subject: media: usbtv: fix brightness and contrast controls
+
+From: Adam Sampson <ats@offog.org>
+
+
+[ Upstream commit b3168c87c0492661badc3e908f977d79e7738a41 ]
+
+Because the brightness and contrast controls share a register,
+usbtv_s_ctrl needs to read the existing values for both controls before
+inserting the new value. However, the code accidentally wrote to the
+registers (from an uninitialised stack array), rather than reading them.
+
+The user-visible effect of this was that adjusting the brightness would
+also set the contrast to a random value, and vice versa -- so it wasn't
+possible to correctly adjust the brightness of usbtv's video output.
+
+Tested with an "EasyDAY" UTV007 device.
+
+Fixes: c53a846c48f2 ("usbtv: add video controls")
+
+Signed-off-by: Adam Sampson <ats@offog.org>
+Reviewed-by: Lubomir Rintel <lkundrak@v3.sk>
+Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/usbtv/usbtv-video.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/usbtv/usbtv-video.c
++++ b/drivers/media/usb/usbtv/usbtv-video.c
+@@ -718,8 +718,8 @@ static int usbtv_s_ctrl(struct v4l2_ctrl
+ */
+ if (ctrl->id == V4L2_CID_BRIGHTNESS || ctrl->id == V4L2_CID_CONTRAST) {
+ ret = usb_control_msg(usbtv->udev,
+- usb_sndctrlpipe(usbtv->udev, 0), USBTV_CONTROL_REG,
+- USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
++ usb_rcvctrlpipe(usbtv->udev, 0), USBTV_CONTROL_REG,
++ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ 0, USBTV_BASE + 0x0244, (void *)data, 3, 0);
+ if (ret < 0)
+ goto error;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Alexey Khoroshilov <khoroshilov@ispras.ru>
+Date: Sat, 14 Oct 2017 01:06:56 +0300
+Subject: mfd: mxs-lradc: Fix error handling in mxs_lradc_probe()
+
+From: Alexey Khoroshilov <khoroshilov@ispras.ru>
+
+
+[ Upstream commit 362741a21a5c4b9ee31e75ce28d63c6d238a745c ]
+
+There is the only path, where mxs_lradc_probe() leaves clk undisabled,
+since it does return instead of goto err_clk.
+
+Found by Linux Driver Verification project (linuxtesting.org).
+
+Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mfd/mxs-lradc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/mfd/mxs-lradc.c
++++ b/drivers/mfd/mxs-lradc.c
+@@ -196,8 +196,10 @@ static int mxs_lradc_probe(struct platfo
+ platform_set_drvdata(pdev, lradc);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+- if (!res)
+- return -ENOMEM;
++ if (!res) {
++ ret = -ENOMEM;
++ goto err_clk;
++ }
+
+ switch (lradc->soc) {
+ case IMX23_LRADC:
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Sat, 30 Sep 2017 11:16:51 +0300
+Subject: misc: pci_endpoint_test: Avoid triggering a BUG()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+
+[ Upstream commit 846df244ebefbc9f7b91e9ae7a5e5a2e69fb4772 ]
+
+If you call ida_simple_remove(&pci_endpoint_test_ida, id) with a
+negative "id" then it triggers an immediate BUG_ON(). Let's not allow
+that.
+
+Fixes: 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/pci_endpoint_test.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/misc/pci_endpoint_test.c
++++ b/drivers/misc/pci_endpoint_test.c
+@@ -590,6 +590,8 @@ static void pci_endpoint_test_remove(str
+
+ if (sscanf(misc_device->name, DRV_MODULE_NAME ".%d", &id) != 1)
+ return;
++ if (id < 0)
++ return;
+
+ misc_deregister(&test->miscdev);
+ ida_simple_remove(&pci_endpoint_test_ida, id);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Wed, 11 Oct 2017 14:14:36 +0530
+Subject: misc: pci_endpoint_test: Fix failure path return values in probe
+
+From: Kishon Vijay Abraham I <kishon@ti.com>
+
+
+[ Upstream commit 80068c93688f6143100859c4856f895801c1a1d9 ]
+
+Return value of pci_endpoint_test_probe is not set properly in a couple of
+failure cases. Fix it here.
+
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/pci_endpoint_test.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/misc/pci_endpoint_test.c
++++ b/drivers/misc/pci_endpoint_test.c
+@@ -533,6 +533,7 @@ static int pci_endpoint_test_probe(struc
+
+ test->base = test->bar[test_reg_bar];
+ if (!test->base) {
++ err = -ENOMEM;
+ dev_err(dev, "Cannot perform PCI test without BAR%d\n",
+ test_reg_bar);
+ goto err_iounmap;
+@@ -542,6 +543,7 @@ static int pci_endpoint_test_probe(struc
+
+ id = ida_simple_get(&pci_endpoint_test_ida, 0, 0, GFP_KERNEL);
+ if (id < 0) {
++ err = id;
+ dev_err(dev, "unable to get id\n");
+ goto err_iounmap;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Wei Yongjun <weiyongjun1@huawei.com>
+Date: Mon, 6 Nov 2017 11:11:28 +0000
+Subject: mlxsw: spectrum: Fix error return code in mlxsw_sp_port_create()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+
+[ Upstream commit d86fd113ebbb37726ef7c7cc6fd6d5ce377455d6 ]
+
+Fix to return a negative error code from the VID create error handling
+case instead of 0, as done elsewhere in this function.
+
+Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Reviewed-by: Ido Schimmel <idosch@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+@@ -2974,6 +2974,7 @@ static int mlxsw_sp_port_create(struct m
+ if (IS_ERR(mlxsw_sp_port_vlan)) {
+ dev_err(mlxsw_sp->bus_info->dev, "Port %d: Failed to create VID 1\n",
+ mlxsw_sp_port->local_port);
++ err = PTR_ERR(mlxsw_sp_port_vlan);
+ goto err_port_vlan_get;
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Jan Kara <jack@suse.cz>
+Date: Fri, 3 Nov 2017 12:21:21 +0100
+Subject: mm: Handle 0 flags in _calc_vm_trans() macro
+
+From: Jan Kara <jack@suse.cz>
+
+
+[ Upstream commit 592e254502041f953e84d091eae2c68cba04c10b ]
+
+_calc_vm_trans() does not handle the situation when some of the passed
+flags are 0 (which can happen if these VM flags do not make sense for
+the architecture). Improve the _calc_vm_trans() macro to return 0 in
+such situation. Since all passed flags are constant, this does not add
+any runtime overhead.
+
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/mman.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/linux/mman.h
++++ b/include/linux/mman.h
+@@ -64,8 +64,9 @@ static inline bool arch_validate_prot(un
+ * ("bit1" and "bit2" must be single bits)
+ */
+ #define _calc_vm_trans(x, bit1, bit2) \
++ ((!(bit1) || !(bit2)) ? 0 : \
+ ((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \
+- : ((x) & (bit1)) / ((bit1) / (bit2)))
++ : ((x) & (bit1)) / ((bit1) / (bit2))))
+
+ /*
+ * Combine the mmap "prot" argument into "vm_flags" used internally.
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+Date: Thu, 26 Oct 2017 17:12:33 +0200
+Subject: mtd: spi-nor: stm32-quadspi: Fix uninitialized error return code
+
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+
+
+[ Upstream commit 05521bd3d117704a1458eb4d0c3ae821858658f2 ]
+
+With gcc 4.1.2:
+
+ drivers/mtd/spi-nor/stm32-quadspi.c: In function ‘stm32_qspi_tx_poll’:
+ drivers/mtd/spi-nor/stm32-quadspi.c:230: warning: ‘ret’ may be used uninitialized in this function
+
+Indeed, if stm32_qspi_cmd.len is zero, ret will be uninitialized.
+This length is passed from outside the driver using the
+spi_nor.{read,write}{,_reg}() callbacks.
+
+Several functions in drivers/mtd/spi-nor/spi-nor.c (e.g. write_enable(),
+write_disable(), and erase_chip()) call spi_nor.write_reg() with a zero
+length.
+
+Fix this by returning an explicit zero on success.
+
+Fixes: 0d43d7ab277a048c ("mtd: spi-nor: add driver for STM32 quad spi flash controller")
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Acked-by: Ludovic Barre <ludovic.barre@st.com>
+Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/spi-nor/stm32-quadspi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/spi-nor/stm32-quadspi.c
++++ b/drivers/mtd/spi-nor/stm32-quadspi.c
+@@ -240,12 +240,12 @@ static int stm32_qspi_tx_poll(struct stm
+ STM32_QSPI_FIFO_TIMEOUT_US);
+ if (ret) {
+ dev_err(qspi->dev, "fifo timeout (stat:%#x)\n", sr);
+- break;
++ return ret;
+ }
+ tx_fifo(buf++, qspi->io_base + QUADSPI_DR);
+ }
+
+- return ret;
++ return 0;
+ }
+
+ static int stm32_qspi_tx_mm(struct stm32_qspi *qspi,
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Egil Hjelmeland <privat@egil-hjelmeland.no>
+Date: Tue, 24 Oct 2017 17:14:10 +0200
+Subject: net: dsa: lan9303: Do not disable switch fabric port 0 at .probe
+
+From: Egil Hjelmeland <privat@egil-hjelmeland.no>
+
+
+[ Upstream commit 3c91b0c1de8d013490bbc41ce9ee8810ea5baddd ]
+
+Make the LAN9303 work when lan9303_probe() is called twice.
+
+For some unknown reason the LAN9303 switch fail to forward data when switch
+fabric port 0 TX is disabled during probe. (Write of LAN9303_MAC_TX_CFG_0
+in lan9303_disable_processing_port().)
+
+In that situation the switch fabric seem to receive frames, because the ALR
+is learning addresses. But no frames are transmitted on any of the ports.
+
+In our system lan9303_probe() is called twice, first time
+dsa_register_switch() return -EPROBE_DEFER. As an experiment, modified the
+code to skip writing LAN9303_MAC_TX_CFG_0, port 0 during the first probe.
+Then the switch works as expected.
+
+Resolve the problem by not calling lan9303_disable_processing_port() on
+port 0 during probe. Ports 1 and 2 are still disabled.
+
+Although unsatisfying that the exact failure mechanism is not known,
+the patch should not cause any harm.
+
+Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/dsa/lan9303-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/dsa/lan9303-core.c
++++ b/drivers/net/dsa/lan9303-core.c
+@@ -569,7 +569,7 @@ static int lan9303_disable_processing(st
+ {
+ int p;
+
+- for (p = 0; p < LAN9303_NUM_PORTS; p++) {
++ for (p = 1; p < LAN9303_NUM_PORTS; p++) {
+ int ret = lan9303_disable_processing_port(chip, p);
+
+ if (ret)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Lipeng <lipeng321@huawei.com>
+Date: Tue, 24 Oct 2017 21:02:10 +0800
+Subject: net: hns3: add nic_client check when initialize roce base information
+
+From: Lipeng <lipeng321@huawei.com>
+
+
+[ Upstream commit 3a46f34d20d453f09defb76b11a567647939c0aa ]
+
+Roce driver works base on HNS3 driver.If insmod Roce driver before
+NIC driver there is a error because do not check nic_client. This patch
+adds nic_client check when initialize roce base information.
+
+Fixes: 46a3df9 (net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support)
+
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -3981,7 +3981,7 @@ static int hclge_init_client_instance(st
+ vport->roce.client = client;
+ }
+
+- if (hdev->roce_client) {
++ if (hdev->roce_client && hdev->nic_client) {
+ ret = hclge_init_roce_base_info(vport);
+ if (ret)
+ goto err;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Lipeng <lipeng321@huawei.com>
+Date: Tue, 24 Oct 2017 21:02:11 +0800
+Subject: net: hns3: fix a bug in hclge_uninit_client_instance
+
+From: Lipeng <lipeng321@huawei.com>
+
+
+[ Upstream commit a17dcf3f0124698d1120da71574bf4c339e5a368 ]
+
+HNS3 driver initialize hdev->roce_client and vport->roce.client in
+hclge_init_client_instance, and need set hdev->roce_client and
+vport->roce.client NULL.
+
+If do not set them NULL when uninit, it will fail in the scene:
+insmod hns3.ko, hns-roce.ko, hns-roce-hw-v3.ko successfully, but
+rmmod hns3.ko after rmmod hns-roce-hw-v2.ko and hns-roce.ko.
+This patch fixes the issue.
+
+Fixes: 46a3df9 (net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support)
+
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -4007,13 +4007,19 @@ static void hclge_uninit_client_instance
+
+ for (i = 0; i < hdev->num_vmdq_vport + 1; i++) {
+ vport = &hdev->vport[i];
+- if (hdev->roce_client)
++ if (hdev->roce_client) {
+ hdev->roce_client->ops->uninit_instance(&vport->roce,
+ 0);
++ hdev->roce_client = NULL;
++ vport->roce.client = NULL;
++ }
+ if (client->type == HNAE3_CLIENT_ROCE)
+ return;
+- if (client->ops->uninit_instance)
++ if (client->ops->uninit_instance) {
+ client->ops->uninit_instance(&vport->nic, 0);
++ hdev->nic_client = NULL;
++ vport->nic.client = NULL;
++ }
+ }
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Lipeng <lipeng321@huawei.com>
+Date: Mon, 23 Oct 2017 19:51:01 +0800
+Subject: net: hns3: fix a bug when alloc new buffer
+
+From: Lipeng <lipeng321@huawei.com>
+
+
+[ Upstream commit b9077428ec5569aacb2952d8a2ffb51c8988d3c2 ]
+
+When alloce new buffer to HW, should unmap the old buffer first.
+This old code map the old buffer but not unmap the old buffer,
+this patch fixes it.
+
+Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
+
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+@@ -1586,7 +1586,7 @@ out_buffer_fail:
+ static void hns3_replace_buffer(struct hns3_enet_ring *ring, int i,
+ struct hns3_desc_cb *res_cb)
+ {
+- hns3_map_buffer(ring, &ring->desc_cb[i]);
++ hns3_unmap_buffer(ring, &ring->desc_cb[i]);
+ ring->desc_cb[i] = *res_cb;
+ ring->desc[i].addr = cpu_to_le64(ring->desc_cb[i].dma);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: qumingguang <qumingguang@huawei.com>
+Date: Thu, 2 Nov 2017 20:45:22 +0800
+Subject: net: hns3: Fix a misuse to devm_free_irq
+
+From: qumingguang <qumingguang@huawei.com>
+
+
+[ Upstream commit ae064e6123f89f90af7e4ea190cc0c612643ca93 ]
+
+we should use free_irq to free the nic irq during the unloading time.
+because we use request_irq to apply it when nic up. It will crash if
+up net device after reset the port. This patch fixes the issue.
+
+Signed-off-by: qumingguang <qumingguang@huawei.com>
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+@@ -2460,9 +2460,8 @@ static int hns3_nic_uninit_vector_data(s
+ (void)irq_set_affinity_hint(
+ priv->tqp_vector[i].vector_irq,
+ NULL);
+- devm_free_irq(&pdev->dev,
+- priv->tqp_vector[i].vector_irq,
+- &priv->tqp_vector[i]);
++ free_irq(priv->tqp_vector[i].vector_irq,
++ &priv->tqp_vector[i]);
+ }
+
+ priv->ring_data[i].ring->irq_init_flag = HNS3_VECTOR_NOT_INITED;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Fuyun Liang <liangfuyun1@huawei.com>
+Date: Fri, 3 Nov 2017 12:18:26 +0800
+Subject: net: hns3: fix for getting advertised_caps in hns3_get_link_ksettings
+
+From: Fuyun Liang <liangfuyun1@huawei.com>
+
+
+[ Upstream commit 2b39cabb2a283cea0c3d96d9370575371726164f ]
+
+This patch fixes a bug for ethtool's get_link_ksettings().
+The advertising for autoneg is always added to advertised_caps
+whether autoneg is enable or disable. This patch fixes it.
+
+Fixes: 496d03e (net: hns3: Add Ethtool support to HNS3 driver)
+Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
+@@ -375,6 +375,9 @@ static int hns3_get_link_ksettings(struc
+ break;
+ }
+
++ if (!cmd->base.autoneg)
++ advertised_caps &= ~HNS3_LM_AUTONEG_BIT;
++
+ /* now, map driver link modes to ethtool link modes */
+ hns3_driv_to_eth_caps(supported_caps, cmd, false);
+ hns3_driv_to_eth_caps(advertised_caps, cmd, true);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Lipeng <lipeng321@huawei.com>
+Date: Tue, 24 Oct 2017 21:02:09 +0800
+Subject: net: hns3: fix the bug of hns3_set_txbd_baseinfo
+
+From: Lipeng <lipeng321@huawei.com>
+
+
+[ Upstream commit 7036d26f328f12a323069eb16d965055b4cb3795 ]
+
+The SC bits of TX BD mean switch control. For this area, value 0
+indicates no switch control, the packet is routed according to the
+forwarding table. Value 1 indicates that the packet is transmitted
+to the network bypassing the forwarding table.
+
+As HNS3 driver need support VF later, VF conmunicate with its own
+PF need forwarding table. This patch sets SC bits of TX BD 0 and use
+forwarding table.
+
+Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
+
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+@@ -721,7 +721,7 @@ static void hns3_set_txbd_baseinfo(u16 *
+ HNS3_TXD_BDTYPE_M, 0);
+ hnae_set_bit(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_FE_B, !!frag_end);
+ hnae_set_bit(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_VLD_B, 1);
+- hnae_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_SC_M, HNS3_TXD_SC_S, 1);
++ hnae_set_field(*bdtp_fe_sc_vld_ra_ri, HNS3_TXD_SC_M, HNS3_TXD_SC_S, 0);
+ }
+
+ static int hns3_fill_desc(struct hns3_enet_ring *ring, void *priv,
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Lipeng <lipeng321@huawei.com>
+Date: Mon, 23 Oct 2017 19:51:02 +0800
+Subject: net: hns3: fix the bug when map buffer fail
+
+From: Lipeng <lipeng321@huawei.com>
+
+
+[ Upstream commit 564883bb4dc1a4f3cba6344e77743175694b0761 ]
+
+If one buffer had been recieved to stack, driver will alloc a new buffer,
+map the buffer to device and replace the old buffer. When map fail, should
+only free the new alloced buffer, but not free all buffers in the ring.
+
+Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
+
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+@@ -1546,7 +1546,7 @@ static int hns3_reserve_buffer_map(struc
+ return 0;
+
+ out_with_buf:
+- hns3_free_buffers(ring);
++ hns3_free_buffer(ring, cb);
+ out:
+ return ret;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Lipeng <lipeng321@huawei.com>
+Date: Mon, 23 Oct 2017 19:51:05 +0800
+Subject: net: hns3: fix the TX/RX ring.queue_index in hns3_ring_get_cfg
+
+From: Lipeng <lipeng321@huawei.com>
+
+
+[ Upstream commit 66b447301ac710ee237dba8b653244018fbb6168 ]
+
+The interface hns3_ring_get_cfg only update TX ring queue_index,
+but do not update RX ring queue_index. This patch fixes it.
+
+Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
+
+Signed-off-by: Lipeng <lipeng321@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+@@ -2488,16 +2488,16 @@ static int hns3_ring_get_cfg(struct hnae
+
+ if (ring_type == HNAE3_RING_TYPE_TX) {
+ ring_data[q->tqp_index].ring = ring;
++ ring_data[q->tqp_index].queue_index = q->tqp_index;
+ ring->io_base = (u8 __iomem *)q->io_base + HNS3_TX_REG_OFFSET;
+ } else {
+ ring_data[q->tqp_index + queue_num].ring = ring;
++ ring_data[q->tqp_index + queue_num].queue_index = q->tqp_index;
+ ring->io_base = q->io_base;
+ }
+
+ hnae_set_bit(ring->flag, HNAE3_RING_TYPE_B, ring_type);
+
+- ring_data[q->tqp_index].queue_index = q->tqp_index;
+-
+ ring->tqp = q;
+ ring->desc = NULL;
+ ring->desc_cb = NULL;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: KUWAZAWA Takuya <albatross0@gmail.com>
+Date: Sun, 15 Oct 2017 20:54:10 +0900
+Subject: netfilter: ipvs: Fix inappropriate output of procfs
+
+From: KUWAZAWA Takuya <albatross0@gmail.com>
+
+
+[ Upstream commit c5504f724c86ee925e7ffb80aa342cfd57959b13 ]
+
+Information about ipvs in different network namespace can be seen via procfs.
+
+How to reproduce:
+
+ # ip netns add ns01
+ # ip netns add ns02
+ # ip netns exec ns01 ip a add dev lo 127.0.0.1/8
+ # ip netns exec ns02 ip a add dev lo 127.0.0.1/8
+ # ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80
+ # ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80
+
+The ipvsadm displays information about its own network namespace only.
+
+ # ip netns exec ns01 ipvsadm -Ln
+ IP Virtual Server version 1.2.1 (size=4096)
+ Prot LocalAddress:Port Scheduler Flags
+ -> RemoteAddress:Port Forward Weight ActiveConn InActConn
+ TCP 10.1.1.1:80 wlc
+
+ # ip netns exec ns02 ipvsadm -Ln
+ IP Virtual Server version 1.2.1 (size=4096)
+ Prot LocalAddress:Port Scheduler Flags
+ -> RemoteAddress:Port Forward Weight ActiveConn InActConn
+ TCP 10.1.1.2:80 wlc
+
+But I can see information about other network namespace via procfs.
+
+ # ip netns exec ns01 cat /proc/net/ip_vs
+ IP Virtual Server version 1.2.1 (size=4096)
+ Prot LocalAddress:Port Scheduler Flags
+ -> RemoteAddress:Port Forward Weight ActiveConn InActConn
+ TCP 0A010101:0050 wlc
+ TCP 0A010102:0050 wlc
+
+ # ip netns exec ns02 cat /proc/net/ip_vs
+ IP Virtual Server version 1.2.1 (size=4096)
+ Prot LocalAddress:Port Scheduler Flags
+ -> RemoteAddress:Port Forward Weight ActiveConn InActConn
+ TCP 0A010102:0050 wlc
+
+Signed-off-by: KUWAZAWA Takuya <albatross0@gmail.com>
+Acked-by: Julian Anastasov <ja@ssi.bg>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/net/netfilter/ipvs/ip_vs_ctl.c
++++ b/net/netfilter/ipvs/ip_vs_ctl.c
+@@ -2034,12 +2034,16 @@ static int ip_vs_info_seq_show(struct se
+ seq_puts(seq,
+ " -> RemoteAddress:Port Forward Weight ActiveConn InActConn\n");
+ } else {
++ struct net *net = seq_file_net(seq);
++ struct netns_ipvs *ipvs = net_ipvs(net);
+ const struct ip_vs_service *svc = v;
+ const struct ip_vs_iter *iter = seq->private;
+ const struct ip_vs_dest *dest;
+ struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler);
+ char *sched_name = sched ? sched->name : "none";
+
++ if (svc->ipvs != ipvs)
++ return 0;
+ if (iter->table == ip_vs_svc_table) {
+ #ifdef CONFIG_IP_VS_IPV6
+ if (svc->af == AF_INET6)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Wei Yongjun <weiyongjun1@huawei.com>
+Date: Tue, 17 Oct 2017 12:11:46 +0000
+Subject: nullb: fix error return code in null_init()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+
+[ Upstream commit 30c516d750396c5f3ec9cb04c9e025c25e91495e ]
+
+Fix to return error code -ENOMEM from the null_alloc_dev() error
+handling case instead of 0, as done elsewhere in this function.
+
+Fixes: 2984c8684f96 ("nullb: factor disk parameters")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/null_blk.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/block/null_blk.c
++++ b/drivers/block/null_blk.c
+@@ -1985,8 +1985,10 @@ static int __init null_init(void)
+
+ for (i = 0; i < nr_devices; i++) {
+ dev = null_alloc_dev();
+- if (!dev)
++ if (!dev) {
++ ret = -ENOMEM;
+ goto err_dev;
++ }
+ ret = null_add_dev(dev);
+ if (ret) {
+ null_free_dev(dev);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Christoph Hellwig <hch@lst.de>
+Date: Wed, 18 Oct 2017 13:20:01 +0200
+Subject: nvme: use kref_get_unless_zero in nvme_find_get_ns
+
+From: Christoph Hellwig <hch@lst.de>
+
+
+[ Upstream commit 2dd4122854f697afc777582d18548dded03ce5dd ]
+
+For kref_get_unless_zero to protect against lookup vs free races we need
+to use it in all places where we aren't guaranteed to already hold a
+reference. There is no such guarantee in nvme_find_get_ns, so switch to
+kref_get_unless_zero in this function.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -2299,7 +2299,8 @@ static struct nvme_ns *nvme_find_get_ns(
+ mutex_lock(&ctrl->namespaces_mutex);
+ list_for_each_entry(ns, &ctrl->namespaces, list) {
+ if (ns->ns_id == nsid) {
+- kref_get(&ns->kref);
++ if (!kref_get_unless_zero(&ns->kref))
++ continue;
+ ret = ns;
+ break;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Alex Williamson <alex.williamson@redhat.com>
+Date: Wed, 11 Oct 2017 15:35:56 -0600
+Subject: PCI: Detach driver before procfs & sysfs teardown on device remove
+
+From: Alex Williamson <alex.williamson@redhat.com>
+
+
+[ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ]
+
+When removing a device, for example a VF being removed due to SR-IOV
+teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
+hot-unplug, we first remove the procfs and sysfs attributes for the device
+before attempting to release the device from any driver bound to it.
+Unbinding the driver from the device can take time. The device might need
+to write out data or it might be actively in use. If it's in use by
+userspace through a vfio driver, the unbind might block until the user
+releases the device. This leads to a potentially non-trivial amount of
+time where the device exists, but we've torn down the interfaces that
+userspace uses to examine devices, for instance lspci might generate this
+sort of error:
+
+ pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
+ lspci: Unable to read the standard configuration space header of device 0000:01:0a.3
+
+We don't seem to have any dependence on this teardown ordering in the
+kernel, so let's unbind the driver first, which is also more symmetric with
+the instantiation of the device in pci_bus_add_device().
+
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/remove.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/remove.c
++++ b/drivers/pci/remove.c
+@@ -19,9 +19,9 @@ static void pci_stop_dev(struct pci_dev
+ pci_pme_active(dev, false);
+
+ if (dev->is_added) {
++ device_release_driver(&dev->dev);
+ pci_proc_detach_device(dev);
+ pci_remove_sysfs_dev_files(dev);
+- device_release_driver(&dev->dev);
+ dev->is_added = 0;
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Fri, 13 Oct 2017 21:35:43 +0300
+Subject: PCI: Do not allocate more buses than available in parent
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+
+[ Upstream commit a20c7f36bd3d20d245616ae223bb9d05dfb6f050 ]
+
+One can ask more buses to be reserved for hotplug bridges by passing
+pci=hpbussize=N in the kernel command line. If the parent bus does not
+have enough bus space available we incorrectly create child bus with the
+requested number of subordinate buses.
+
+In the example below hpbussize is set to one more than we have available
+buses in the root port:
+
+ pci 0000:07:00.0: [8086:1578] type 01 class 0x060400
+ pci 0000:07:00.0: scanning [bus 00-00] behind bridge, pass 0
+ pci 0000:07:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ pci 0000:07:00.0: scanning [bus 00-00] behind bridge, pass 1
+ pci_bus 0000:08: busn_res: can not insert [bus 08-ff] under [bus 07-3f] (conflicts with (null) [bus 07-3f])
+ pci_bus 0000:08: scanning bus
+ ...
+ pci_bus 0000:0a: bus scan returning with max=40
+ pci_bus 0000:0a: busn_res: [bus 0a-ff] end is updated to 40
+ pci_bus 0000:0a: [bus 0a-40] partially hidden behind bridge 0000:07 [bus 07-3f]
+ pci_bus 0000:08: bus scan returning with max=40
+ pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 40
+
+Instead of allowing this, limit the subordinate number to be less than or
+equal the maximum subordinate number allocated for the parent bus (if it
+has any).
+
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+[bhelgaas: remove irrelevant dmesg messages]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/probe.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/probe.c
++++ b/drivers/pci/probe.c
+@@ -1076,7 +1076,8 @@ int pci_scan_bridge(struct pci_bus *bus,
+ child = pci_add_new_bus(bus, dev, max+1);
+ if (!child)
+ goto out;
+- pci_bus_insert_busn_res(child, max+1, 0xff);
++ pci_bus_insert_busn_res(child, max+1,
++ bus->busn_res.end);
+ }
+ max++;
+ buses = (buses & 0xff000000)
+@@ -2433,6 +2434,10 @@ unsigned int pci_scan_child_bus(struct p
+ if (bus->self && bus->self->is_hotplug_bridge && pci_hotplug_bus_size) {
+ if (max - bus->busn_res.start < pci_hotplug_bus_size - 1)
+ max = bus->busn_res.start + pci_hotplug_bus_size - 1;
++
++ /* Do not allocate more buses than we have room left */
++ if (max > bus->busn_res.end)
++ max = bus->busn_res.end;
+ }
+
+ /*
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Qiang <zhengqiang10@huawei.com>
+Date: Thu, 28 Sep 2017 11:54:34 +0800
+Subject: PCI/PME: Handle invalid data when reading Root Status
+
+From: Qiang <zhengqiang10@huawei.com>
+
+
+[ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ]
+
+PCIe PME and native hotplug share the same interrupt number, so hotplug
+interrupts are also processed by PME. In some cases, e.g., a Link Down
+interrupt, a device may be present but unreachable, so when we try to
+read its Root Status register, the read fails and we get all ones data
+(0xffffffff).
+
+Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e.,
+"some device has asserted PME," so we scheduled pcie_pme_work_fn(). This
+caused an infinite loop because pcie_pme_work_fn() tried to handle PME
+requests until PCI_EXP_RTSTA_PME is cleared, but with the link down,
+PCI_EXP_RTSTA_PME can't be cleared.
+
+Check for the invalid 0xffffffff data everywhere we read the Root Status
+register.
+
+1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from
+non-existent devices") added similar checks in the hotplug driver.
+
+Signed-off-by: Qiang Zheng <zhengqiang10@huawei.com>
+[bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow
+other similar checks]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pcie/pme.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/pcie/pme.c
++++ b/drivers/pci/pcie/pme.c
+@@ -226,6 +226,9 @@ static void pcie_pme_work_fn(struct work
+ break;
+
+ pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
++ if (rtsta == (u32) ~0)
++ break;
++
+ if (rtsta & PCI_EXP_RTSTA_PME) {
+ /*
+ * Clear PME status of the port. If there are other
+@@ -273,7 +276,7 @@ static irqreturn_t pcie_pme_irq(int irq,
+ spin_lock_irqsave(&data->lock, flags);
+ pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
+
+- if (!(rtsta & PCI_EXP_RTSTA_PME)) {
++ if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) {
+ spin_unlock_irqrestore(&data->lock, flags);
+ return IRQ_NONE;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Wed, 11 Oct 2017 11:57:15 +0200
+Subject: pinctrl: adi2: Fix Kconfig build problem
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+
+[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]
+
+The build robot is complaining on Blackfin:
+
+drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
+>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
+ pointer to incomplete type 'struct gpio_port_t'
+ writew(readw(®s->port_fer) & ~BIT(offset),
+ ^~
+drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
+>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
+pointer to incomplete type 'struct bfin_pint_regs'
+ if (readl(®s->invert_set) & pintbit)
+ ^~
+It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
+to compile.
+
+The Blackfin architecture was re-defining the Kconfig
+PINCTRL symbol which is not OK, so replaced this with
+PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
+just like most arches do.
+
+Further, the old GPIO driver symbol GPIO_ADI was possible to
+select at the same time as selecting PINCTRL. This was not
+working because the arch-local <asm/gpio.h> header contains
+an explicit #ifndef PINCTRL clause making compilation break
+if you combine them. The same is true for DEBUG_MMRS.
+
+Make sure the ADI2 pinctrl driver is not selected at the same
+time as the old GPIO implementation. (This should be converted
+to use gpiolib or pincontrol and move to drivers/...) Also make
+sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
+the same time as the new PINCTRL implementation, and only make
+PINCTRL_ADI2 selectable for the Blackfin families that actually
+have it.
+
+This way it is still possible to add e.g. I2C-based pin
+control expanders on the Blackfin.
+
+Cc: Steven Miao <realmz6@gmail.com>
+Cc: Huanhuan Feng <huanhuan.feng@analog.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/blackfin/Kconfig | 7 +++++--
+ arch/blackfin/Kconfig.debug | 1 +
+ drivers/pinctrl/Kconfig | 3 ++-
+ 3 files changed, 8 insertions(+), 3 deletions(-)
+
+--- a/arch/blackfin/Kconfig
++++ b/arch/blackfin/Kconfig
+@@ -321,11 +321,14 @@ config BF53x
+
+ config GPIO_ADI
+ def_bool y
++ depends on !PINCTRL
+ depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
+
+-config PINCTRL
++config PINCTRL_BLACKFIN_ADI2
+ def_bool y
+- depends on BF54x || BF60x
++ depends on (BF54x || BF60x)
++ select PINCTRL
++ select PINCTRL_ADI2
+
+ config MEM_MT48LC64M4A2FB_7E
+ bool
+--- a/arch/blackfin/Kconfig.debug
++++ b/arch/blackfin/Kconfig.debug
+@@ -18,6 +18,7 @@ config DEBUG_VERBOSE
+
+ config DEBUG_MMRS
+ tristate "Generate Blackfin MMR tree"
++ depends on !PINCTRL
+ select DEBUG_FS
+ help
+ Create a tree of Blackfin MMRs via the debugfs tree. If
+--- a/drivers/pinctrl/Kconfig
++++ b/drivers/pinctrl/Kconfig
+@@ -33,7 +33,8 @@ config DEBUG_PINCTRL
+
+ config PINCTRL_ADI2
+ bool "ADI pin controller driver"
+- depends on BLACKFIN
++ depends on (BF54x || BF60x)
++ depends on !GPIO_ADI
+ select PINMUX
+ select IRQ_DOMAIN
+ help
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Osama Khan <osama.khan@ericsson.com>
+Date: Sat, 21 Oct 2017 10:42:21 +0000
+Subject: platform/x86: hp_accel: Add quirk for HP ProBook 440 G4
+
+From: Osama Khan <osama.khan@ericsson.com>
+
+
+[ Upstream commit 163ca80013aafb6dc9cb295de3db7aeab9ab43f8 ]
+
+Added support for HP ProBook 440 G4 laptops by including the accelerometer
+orientation quirk for that device. Testing was performed based on the
+axis orientation guidelines here:
+https://www.kernel.org/doc/Documentation/misc-devices/lis3lv02d
+which states "If the left side is elevated, X increases (becomes positive)".
+
+When tested, on lifting the left edge, x values became increasingly negative
+thus indicating an inverted x-axis on the installed lis3lv02d chip.
+This was compensated by adding an entry for this device in hp_accel.c
+specifying the quirk as x_inverted. The patch was tested on a
+ProBook 440 G4 device and x-axis as well as y and z-axis values are now
+generated as per spec.
+
+Signed-off-by: Osama Khan <osama.khan@ericsson.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp_accel.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/platform/x86/hp_accel.c
++++ b/drivers/platform/x86/hp_accel.c
+@@ -240,6 +240,7 @@ static const struct dmi_system_id lis3lv
+ AXIS_DMI_MATCH("HDX18", "HP HDX 18", x_inverted),
+ AXIS_DMI_MATCH("HPB432x", "HP ProBook 432", xy_rotated_left),
+ AXIS_DMI_MATCH("HPB440G3", "HP ProBook 440 G3", x_inverted_usd),
++ AXIS_DMI_MATCH("HPB440G4", "HP ProBook 440 G4", x_inverted),
+ AXIS_DMI_MATCH("HPB442x", "HP ProBook 442", xy_rotated_left),
+ AXIS_DMI_MATCH("HPB452x", "HP ProBook 452", y_inverted),
+ AXIS_DMI_MATCH("HPB522x", "HP ProBook 522", xy_swap),
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Date: Sun, 29 Oct 2017 02:49:54 -0700
+Subject: platform/x86: intel_punit_ipc: Fix resource ioremap warning
+
+From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+
+
+[ Upstream commit 6cc8cbbc8868033f279b63e98b26b75eaa0006ab ]
+
+For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not
+mandatory. So when PMC IPC driver creates a PUNIT device, if these
+resources are not available then it creates dummy resource entries for
+these missing resources. But during PUNIT device probe, doing ioremap on
+these dummy resources generates following warning messages.
+
+intel_punit_ipc: can't request region for resource [mem 0x00000000]
+intel_punit_ipc: can't request region for resource [mem 0x00000000]
+intel_punit_ipc: can't request region for resource [mem 0x00000000]
+intel_punit_ipc: can't request region for resource [mem 0x00000000]
+
+This patch fixes this issue by adding extra check for resource size
+before performing ioremap operation.
+
+Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel_punit_ipc.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/platform/x86/intel_punit_ipc.c
++++ b/drivers/platform/x86/intel_punit_ipc.c
+@@ -252,28 +252,28 @@ static int intel_punit_get_bars(struct p
+ * - GTDRIVER_IPC BASE_IFACE
+ */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+- if (res) {
++ if (res && resource_size(res) > 1) {
+ addr = devm_ioremap_resource(&pdev->dev, res);
+ if (!IS_ERR(addr))
+ punit_ipcdev->base[ISPDRIVER_IPC][BASE_DATA] = addr;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
+- if (res) {
++ if (res && resource_size(res) > 1) {
+ addr = devm_ioremap_resource(&pdev->dev, res);
+ if (!IS_ERR(addr))
+ punit_ipcdev->base[ISPDRIVER_IPC][BASE_IFACE] = addr;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 4);
+- if (res) {
++ if (res && resource_size(res) > 1) {
+ addr = devm_ioremap_resource(&pdev->dev, res);
+ if (!IS_ERR(addr))
+ punit_ipcdev->base[GTDRIVER_IPC][BASE_DATA] = addr;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 5);
+- if (res) {
++ if (res && resource_size(res) > 1) {
+ addr = devm_ioremap_resource(&pdev->dev, res);
+ if (!IS_ERR(addr))
+ punit_ipcdev->base[GTDRIVER_IPC][BASE_IFACE] = addr;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Markus Elfring <elfring@users.sourceforge.net>
+Date: Wed, 1 Nov 2017 18:42:45 +0100
+Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
+
+From: Markus Elfring <elfring@users.sourceforge.net>
+
+
+[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ]
+
+Source code review for a specific software refactoring showed the need
+for another correction because the error code "-1" was returned so far
+if a call of the function "sony_call_snc_handle" failed here.
+Thus assign the return value from these two function calls also to
+the variable "err" and provide it in case of a failure.
+
+Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw")
+Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Link: https://lkml.org/lkml/2017/10/31/463
+Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg@mail.gmail.com>
+Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/sony-laptop.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/drivers/platform/x86/sony-laptop.c
++++ b/drivers/platform/x86/sony-laptop.c
+@@ -1660,17 +1660,19 @@ static int sony_nc_setup_rfkill(struct a
+ if (!rfk)
+ return -ENOMEM;
+
+- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) {
++ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result);
++ if (err < 0) {
+ rfkill_destroy(rfk);
+- return -1;
++ return err;
+ }
+ hwblock = !(result & 0x1);
+
+- if (sony_call_snc_handle(sony_rfkill_handle,
+- sony_rfkill_address[nc_type],
+- &result) < 0) {
++ err = sony_call_snc_handle(sony_rfkill_handle,
++ sony_rfkill_address[nc_type],
++ &result);
++ if (err < 0) {
+ rfkill_destroy(rfk);
+- return -1;
++ return err;
+ }
+ swblock = !(result & 0x2);
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Rajat Jain <rajatja@google.com>
+Date: Tue, 31 Oct 2017 14:44:24 -0700
+Subject: PM / s2idle: Clear the events_check_enabled flag
+
+From: Rajat Jain <rajatja@google.com>
+
+
+[ Upstream commit 95b982b45122c57da2ee0b46cce70775e1d987af ]
+
+Problem: This flag does not get cleared currently in the suspend or
+resume path in the following cases:
+
+ * In case some driver's suspend routine returns an error.
+ * Successful s2idle case
+ * etc?
+
+Why is this a problem: What happens is that the next suspend attempt
+could fail even though the user did not enable the flag by writing to
+/sys/power/wakeup_count. This is 1 use case how the issue can be seen
+(but similar use case with driver suspend failure can be thought of):
+
+ 1. Read /sys/power/wakeup_count
+ 2. echo count > /sys/power/wakeup_count
+ 3. echo freeze > /sys/power/wakeup_count
+ 4. Let the system suspend, and wakeup the system using some wake source
+ that calls pm_wakeup_event() e.g. power button or something.
+ 5. Note that the combined wakeup count would be incremented due
+ to the pm_wakeup_event() in the resume path.
+ 6. After resuming the events_check_enabled flag is still set.
+
+At this point if the user attempts to freeze again (without writing to
+/sys/power/wakeup_count), the suspend would fail even though there has
+been no wake event since the past resume.
+
+Address that by clearing the flag just before a resume is completed,
+so that it is always cleared for the corner cases mentioned above.
+
+Signed-off-by: Rajat Jain <rajatja@google.com>
+Acked-by: Pavel Machek <pavel@ucw.cz>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/power/suspend.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/power/suspend.c
++++ b/kernel/power/suspend.c
+@@ -437,7 +437,6 @@ static int suspend_enter(suspend_state_t
+ error = suspend_ops->enter(state);
+ trace_suspend_resume(TPS("machine_suspend"),
+ state, false);
+- events_check_enabled = false;
+ } else if (*wakeup) {
+ error = -EBUSY;
+ }
+@@ -582,6 +581,7 @@ static int enter_state(suspend_state_t s
+ pm_restore_gfp_mask();
+
+ Finish:
++ events_check_enabled = false;
+ pm_pr_dbg("Finishing wakeup.\n");
+ suspend_finish();
+ Unlock:
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+Date: Wed, 18 Oct 2017 11:16:47 +0200
+Subject: powerpc/ipic: Fix status get and status clear
+
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+
+
+[ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ]
+
+IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
+which is the mask register.
+
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/sysdev/ipic.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/sysdev/ipic.c
++++ b/arch/powerpc/sysdev/ipic.c
+@@ -846,12 +846,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq
+
+ u32 ipic_get_mcp_status(void)
+ {
+- return ipic_read(primary_ipic->regs, IPIC_SERMR);
++ return ipic_read(primary_ipic->regs, IPIC_SERSR);
+ }
+
+ void ipic_clear_mcp_status(u32 mask)
+ {
+- ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
++ ipic_write(primary_ipic->regs, IPIC_SERSR, mask);
+ }
+
+ /* Return an interrupt vector or 0 if no interrupt is pending. */
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: "William A. Kennington III" <wak@google.com>
+Date: Fri, 22 Sep 2017 16:58:00 -0700
+Subject: powerpc/opal: Fix EBUSY bug in acquiring tokens
+
+From: "William A. Kennington III" <wak@google.com>
+
+
+[ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ]
+
+The current code checks the completion map to look for the first token
+that is complete. In some cases, a completion can come in but the
+token can still be on lease to the caller processing the completion.
+If this completed but unreleased token is the first token found in the
+bitmap by another tasks trying to acquire a token, then the
+__test_and_set_bit call will fail since the token will still be on
+lease. The acquisition will then fail with an EBUSY.
+
+This patch reorganizes the acquisition code to look at the
+opal_async_token_map for an unleased token. If the token has no lease
+it must have no outstanding completions so we should never see an
+EBUSY, unless we have leased out too many tokens. Since
+opal_async_get_token_inrerruptible is protected by a semaphore, we
+will practically never see EBUSY anymore.
+
+Fixes: 8d7248232208 ("powerpc/powernv: Infrastructure to support OPAL async completion")
+Signed-off-by: William A. Kennington III <wak@google.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/powernv/opal-async.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/platforms/powernv/opal-async.c
++++ b/arch/powerpc/platforms/powernv/opal-async.c
+@@ -39,18 +39,18 @@ int __opal_async_get_token(void)
+ int token;
+
+ spin_lock_irqsave(&opal_async_comp_lock, flags);
+- token = find_first_bit(opal_async_complete_map, opal_max_async_tokens);
++ token = find_first_zero_bit(opal_async_token_map, opal_max_async_tokens);
+ if (token >= opal_max_async_tokens) {
+ token = -EBUSY;
+ goto out;
+ }
+
+- if (__test_and_set_bit(token, opal_async_token_map)) {
++ if (!__test_and_clear_bit(token, opal_async_complete_map)) {
+ token = -EBUSY;
+ goto out;
+ }
+
+- __clear_bit(token, opal_async_complete_map);
++ __set_bit(token, opal_async_token_map);
+
+ out:
+ spin_unlock_irqrestore(&opal_async_comp_lock, flags);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Mon, 9 Oct 2017 21:52:44 +1100
+Subject: powerpc/perf/hv-24x7: Fix incorrect comparison in memord
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+
+[ Upstream commit 05c14c03138532a3cb2aa29c2960445c8753343b ]
+
+In the hv-24x7 code there is a function memord() which tries to
+implement a sort function return -1, 0, 1. However one of the
+conditions is incorrect, such that it can never be true, because we
+will have already returned.
+
+I don't believe there is a bug in practice though, because the
+comparisons are an optimisation prior to calling memcmp().
+
+Fix it by swapping the second comparision, so it can be true.
+
+Reported-by: David Binderman <dcb314@hotmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/perf/hv-24x7.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/perf/hv-24x7.c
++++ b/arch/powerpc/perf/hv-24x7.c
+@@ -540,7 +540,7 @@ static int memord(const void *d1, size_t
+ {
+ if (s1 < s2)
+ return 1;
+- if (s2 > s1)
++ if (s1 > s2)
+ return -1;
+
+ return memcmp(d1, d2, s1);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Shriya <shriyak@linux.vnet.ibm.com>
+Date: Fri, 13 Oct 2017 10:06:41 +0530
+Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
+
+From: Shriya <shriyak@linux.vnet.ibm.com>
+
+
+[ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ]
+
+The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which
+returns the last frequency requested by the kernel, but may not
+reflect the actual frequency the processor is running at. This patch
+makes a call to cpufreq_get() instead which returns the current
+frequency reported by the hardware.
+
+Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()")
+Signed-off-by: Shriya <shriyak@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/powernv/setup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/powernv/setup.c
++++ b/arch/powerpc/platforms/powernv/setup.c
+@@ -319,7 +319,7 @@ static unsigned long pnv_get_proc_freq(u
+ {
+ unsigned long ret_freq;
+
+- ret_freq = cpufreq_quick_get(cpu) * 1000ul;
++ ret_freq = cpufreq_get(cpu) * 1000ul;
+
+ /*
+ * If the backend cpufreq driver does not exist,
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+Date: Thu, 28 Sep 2017 20:19:20 -0400
+Subject: powerpc/pseries/vio: Dispose of virq mapping on vdevice unregister
+
+From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+
+
+[ Upstream commit b8f89fea599d91e674497aad572613eb63181f31 ]
+
+When a vdevice is DLPAR removed from the system the vio subsystem
+doesn't bother unmapping the virq from the irq_domain. As a result we
+have a virq mapped to a hardware irq that is no longer valid for the
+irq_domain. A side effect is that we are left with /proc/irq/<irq#>
+affinity entries, and attempts to modify the smp_affinity of the irq
+will fail.
+
+In the following observed example the kernel log is spammed by
+ics_rtas_set_affinity errors after the removal of a VSCSI adapter.
+This is a result of irqbalance trying to adjust the affinity every 10
+seconds.
+
+ rpadlpar_io: slot U8408.E8E.10A7ACV-V5-C25 removed
+ ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3
+ ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3
+
+This patch fixes the issue by calling irq_dispose_mapping() on the
+virq of the viodev on unregister.
+
+Fixes: f2ab6219969f ("powerpc/pseries: Add PFO support to the VIO bus")
+Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/pseries/vio.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/powerpc/platforms/pseries/vio.c
++++ b/arch/powerpc/platforms/pseries/vio.c
+@@ -1592,6 +1592,8 @@ ATTRIBUTE_GROUPS(vio_dev);
+ void vio_unregister_device(struct vio_dev *viodev)
+ {
+ device_unregister(&viodev->dev);
++ if (viodev->family == VDEVICE)
++ irq_dispose_mapping(viodev->irq);
+ }
+ EXPORT_SYMBOL(vio_unregister_device);
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Breno Leitao <leitao@debian.org>
+Date: Tue, 17 Oct 2017 16:20:18 -0200
+Subject: powerpc/xmon: Check before calling xive functions
+
+From: Breno Leitao <leitao@debian.org>
+
+
+[ Upstream commit 402e172a2ce76210f2fe921cf419d12103851344 ]
+
+Currently xmon could call XIVE functions from OPAL even if the XIVE is
+disabled or does not exist in the system, as in POWER8 machines. This
+causes the following exception:
+
+ 1:mon> dx
+ cpu 0x1: Vector: 700 (Program Check) at [c000000423c93450]
+ pc: c00000000009cfa4: opal_xive_dump+0x50/0x68
+ lr: c0000000000997b8: opal_return+0x0/0x50
+
+This patch simply checks if XIVE is enabled before calling XIVE
+functions.
+
+Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller")
+Suggested-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/xmon/xmon.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/powerpc/xmon/xmon.c
++++ b/arch/powerpc/xmon/xmon.c
+@@ -2475,6 +2475,11 @@ static void dump_xives(void)
+ unsigned long num;
+ int c;
+
++ if (!xive_enabled()) {
++ printf("Xive disabled on this system\n");
++ return;
++ }
++
+ c = inchar();
+ if (c == 'a') {
+ dump_all_xives();
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Gao Feng <gfree.wind@vip.163.com>
+Date: Tue, 31 Oct 2017 18:25:37 +0800
+Subject: ppp: Destroy the mutex when cleanup
+
+From: Gao Feng <gfree.wind@vip.163.com>
+
+
+[ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ]
+
+The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the
+good readbility, it's better to invoke it in exit func when the init
+func invokes mutex_init.
+
+Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
+Acked-by: Guillaume Nault <g.nault@alphalink.fr>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ppp/ppp_generic.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ppp/ppp_generic.c
++++ b/drivers/net/ppp/ppp_generic.c
+@@ -959,6 +959,7 @@ static __net_exit void ppp_exit_net(stru
+ unregister_netdevice_many(&list);
+ rtnl_unlock();
+
++ mutex_destroy(&pn->all_ppp_mutex);
+ idr_destroy(&pn->units_idr);
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
+Date: Mon, 30 Oct 2017 13:13:46 +0300
+Subject: qtnfmac: modify full Tx queue error reporting
+
+From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
+
+
+[ Upstream commit e9931f984dd1e80adb3b5e095ef175fe383bc92d ]
+
+Under heavy load it is normal that h/w Tx queue is almost full all the time
+and reclaim should be done before transmitting next packet. Warning still
+should be reported as well as s/w Tx queues should be stopped in the
+case when reclaim failed.
+
+Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
++++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+@@ -643,11 +643,11 @@ static int qtnf_tx_queue_ready(struct qt
+ {
+ if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
+ priv->tx_bd_num)) {
+- pr_err_ratelimited("reclaim full Tx queue\n");
+ qtnf_pcie_data_tx_reclaim(priv);
+
+ if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
+ priv->tx_bd_num)) {
++ pr_warn_ratelimited("reclaim full Tx queue\n");
+ priv->tx_full_count++;
+ return 0;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
+Date: Fri, 29 Sep 2017 22:54:19 +0200
+Subject: raid5-ppl: check recovery_offset when performing ppl recovery
+
+From: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
+
+
+[ Upstream commit 07719ff767dcd8cc42050f185d332052f3816546 ]
+
+If starting an array that is undergoing rebuild, make ppl recovery honor
+the recovery_offset of a member disk and don't read data that is not yet
+in-sync.
+
+Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid5-ppl.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5-ppl.c
++++ b/drivers/md/raid5-ppl.c
+@@ -758,7 +758,8 @@ static int ppl_recover_entry(struct ppl_
+ (unsigned long long)sector);
+
+ rdev = conf->disks[dd_idx].rdev;
+- if (!rdev) {
++ if (!rdev || (!test_bit(In_sync, &rdev->flags) &&
++ sector >= rdev->recovery_offset)) {
+ pr_debug("%s:%*s data member disk %d missing\n",
+ __func__, indent, "", dd_idx);
+ update_parity = false;
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: NeilBrown <neilb@suse.com>
+Date: Tue, 17 Oct 2017 16:18:36 +1100
+Subject: raid5: Set R5_Expanded on parity devices as well as data.
+
+From: NeilBrown <neilb@suse.com>
+
+
+[ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ]
+
+When reshaping a fully degraded raid5/raid6 to a larger
+nubmer of devices, the new device(s) are not in-sync
+and so that can make the newly grown stripe appear to be
+"failed".
+To avoid this, we set the R5_Expanded flag to say "Even though
+this device is not fully in-sync, this block is safe so
+don't treat the device as failed for this stripe".
+This flag is set for data devices, not not for parity devices.
+
+Consequently, if you have a RAID6 with two devices that are partly
+recovered and a spare, and start a reshape to include the spare,
+then when the reshape gets past the point where the recovery was
+up to, it will think the stripes are failed and will get into
+an infinite loop, failing to make progress.
+
+So when contructing parity on an EXPAND_READY stripe,
+set R5_Expanded.
+
+Reported-by: Curt <lightspd@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid5.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -1818,8 +1818,11 @@ static void ops_complete_reconstruct(voi
+ struct r5dev *dev = &sh->dev[i];
+
+ if (dev->written || i == pd_idx || i == qd_idx) {
+- if (!discard && !test_bit(R5_SkipCopy, &dev->flags))
++ if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) {
+ set_bit(R5_UPTODATE, &dev->flags);
++ if (test_bit(STRIPE_EXPAND_READY, &sh->state))
++ set_bit(R5_Expanded, &dev->flags);
++ }
+ if (fua)
+ set_bit(R5_WantFUA, &dev->flags);
+ if (sync)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Bart Van Assche <bart.vanassche@wdc.com>
+Date: Wed, 11 Oct 2017 10:48:45 -0700
+Subject: RDMA/cma: Avoid triggering undefined behavior
+
+From: Bart Van Assche <bart.vanassche@wdc.com>
+
+
+[ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ]
+
+According to the C standard the behavior of computations with
+integer operands is as follows:
+* A computation involving unsigned operands can never overflow,
+ because a result that cannot be represented by the resulting
+ unsigned integer type is reduced modulo the number that is one
+ greater than the largest value that can be represented by the
+ resulting type.
+* The behavior for signed integer underflow and overflow is
+ undefined.
+
+Hence only use unsigned integers when checking for integer
+overflow.
+
+This patch is what I came up with after having analyzed the
+following smatch warnings:
+
+drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
+drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
+
+Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
+Acked-by: Sean Hefty <sean.hefty@intel.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/cma.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -1540,7 +1540,7 @@ static struct rdma_id_private *cma_id_fr
+ return id_priv;
+ }
+
+-static inline int cma_user_data_offset(struct rdma_id_private *id_priv)
++static inline u8 cma_user_data_offset(struct rdma_id_private *id_priv)
+ {
+ return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cma_hdr);
+ }
+@@ -1942,7 +1942,8 @@ static int cma_req_handler(struct ib_cm_
+ struct rdma_id_private *listen_id, *conn_id = NULL;
+ struct rdma_cm_event event;
+ struct net_device *net_dev;
+- int offset, ret;
++ u8 offset;
++ int ret;
+
+ listen_id = cma_id_from_event(cm_id, ib_event, &net_dev);
+ if (IS_ERR(listen_id))
+@@ -3440,7 +3441,8 @@ static int cma_resolve_ib_udp(struct rdm
+ struct ib_cm_sidr_req_param req;
+ struct ib_cm_id *id;
+ void *private_data;
+- int offset, ret;
++ u8 offset;
++ int ret;
+
+ memset(&req, 0, sizeof req);
+ offset = cma_user_data_offset(id_priv);
+@@ -3497,7 +3499,8 @@ static int cma_connect_ib(struct rdma_id
+ struct rdma_route *route;
+ void *private_data;
+ struct ib_cm_id *id;
+- int offset, ret;
++ u8 offset;
++ int ret;
+
+ memset(&req, 0, sizeof req);
+ offset = cma_user_data_offset(id_priv);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Leon Romanovsky <leon@kernel.org>
+Date: Wed, 25 Oct 2017 07:41:11 +0300
+Subject: RDMA/cxgb4: Declare stag as __be32
+
+From: Leon Romanovsky <leon@kernel.org>
+
+
+[ Upstream commit 35fb2a88ed4b77356fa679a8525c869a3594e287 ]
+
+The scqe.stag is actually __b32, fix it.
+
+ drivers/infiniband/hw/cxgb4/cq.c:754:52: warning: cast to restricted __be32
+
+Cc: Steve Wise <swise@opengridcomputing.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Reviewed-by: Steve Wise <swise@opengridcomputing.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/cxgb4/t4.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/cxgb4/t4.h
++++ b/drivers/infiniband/hw/cxgb4/t4.h
+@@ -171,7 +171,7 @@ struct t4_cqe {
+ __be32 msn;
+ } rcqe;
+ struct {
+- u32 stag;
++ __be32 stag;
+ u16 nada2;
+ u16 cidx;
+ } scqe;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Arun Kumar Neelakantam <aneela@codeaurora.org>
+Date: Mon, 30 Oct 2017 11:11:24 +0530
+Subject: rpmsg: glink: Initialize the "intent_req_comp" completion variable
+
+From: Arun Kumar Neelakantam <aneela@codeaurora.org>
+
+
+[ Upstream commit 2394facb17bcace4b3c19b50202177a5d8903b64 ]
+
+The "intent_req_comp" variable is used without initialization which
+results in NULL pointer dereference in qcom_glink_request_intent().
+
+we need to initialize the completion variable before using it.
+
+Fixes: 27b9c5b66b23 ("rpmsg: glink: Request for intents when unavailable")
+Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rpmsg/qcom_glink_native.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/rpmsg/qcom_glink_native.c
++++ b/drivers/rpmsg/qcom_glink_native.c
+@@ -227,6 +227,7 @@ static struct glink_channel *qcom_glink_
+
+ init_completion(&channel->open_req);
+ init_completion(&channel->open_ack);
++ init_completion(&channel->intent_req_comp);
+
+ INIT_LIST_HEAD(&channel->done_intents);
+ INIT_WORK(&channel->intent_work, qcom_glink_rx_done_work);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Philipp Zabel <p.zabel@pengutronix.de>
+Date: Tue, 7 Nov 2017 13:12:17 +0100
+Subject: rtc: pcf8563: fix output clock rate
+
+From: Philipp Zabel <p.zabel@pengutronix.de>
+
+
+[ Upstream commit a3350f9c57ffad569c40f7320b89da1f3061c5bb ]
+
+The pcf8563_clkout_recalc_rate function erroneously ignores the
+frequency index read from the CLKO register and always returns
+32768 Hz.
+
+Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework")
+Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
+Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rtc/rtc-pcf8563.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/rtc/rtc-pcf8563.c
++++ b/drivers/rtc/rtc-pcf8563.c
+@@ -422,7 +422,7 @@ static unsigned long pcf8563_clkout_reca
+ return 0;
+
+ buf &= PCF8563_REG_CLKO_F_MASK;
+- return clkout_rates[ret];
++ return clkout_rates[buf];
+ }
+
+ static long pcf8563_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Jia-Ju Bai <baijiaju1990@163.com>
+Date: Sun, 8 Oct 2017 19:54:45 +0800
+Subject: rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_createbss_cmd
+
+From: Jia-Ju Bai <baijiaju1990@163.com>
+
+
+[ Upstream commit 2bf9806d4228f7a6195f8e03eda0479d2a93b411 ]
+
+The driver may sleep under a spinlock, and the function call path is:
+rtw_surveydone_event_callback(acquire the spinlock)
+ rtw_createbss_cmd
+ kzalloc(GFP_KERNEL) --> may sleep
+
+To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
+This bug is found by my static analysis tool and my code review.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
++++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
+@@ -333,7 +333,7 @@ u8 rtw_createbss_cmd(struct adapter *pa
+ else
+ RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, (" createbss for SSid:%s\n", pmlmepriv->assoc_ssid.Ssid));
+
+- pcmd = kzalloc(sizeof(struct cmd_obj), GFP_KERNEL);
++ pcmd = kzalloc(sizeof(struct cmd_obj), GFP_ATOMIC);
+ if (!pcmd) {
+ res = _FAIL;
+ goto exit;
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Jia-Ju Bai <baijiaju1990@163.com>
+Date: Sun, 8 Oct 2017 19:54:07 +0800
+Subject: rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd
+
+From: Jia-Ju Bai <baijiaju1990@163.com>
+
+
+[ Upstream commit 08880f8e08cbd814e870e9d3ab9530abc1bce226 ]
+
+The driver may sleep under a spinlock, and the function call path is:
+rtw_set_802_11_bssid(acquire the spinlock)
+ rtw_disassoc_cmd
+ kzalloc(GFP_KERNEL) --> may sleep
+
+To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
+This bug is found by my static analysis tool and my code review.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
++++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
+@@ -508,7 +508,7 @@ u8 rtw_disassoc_cmd(struct adapter *pada
+
+ if (enqueue) {
+ /* need enqueue, prepare cmd_obj and enqueue */
+- cmdobj = kzalloc(sizeof(*cmdobj), GFP_KERNEL);
++ cmdobj = kzalloc(sizeof(*cmdobj), GFP_ATOMIC);
+ if (!cmdobj) {
+ res = _FAIL;
+ kfree(param);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Tushar Dave <tushar.n.dave@oracle.com>
+Date: Fri, 27 Oct 2017 16:12:30 -0700
+Subject: samples/bpf: adjust rlimit RLIMIT_MEMLOCK for xdp1
+
+From: Tushar Dave <tushar.n.dave@oracle.com>
+
+
+[ Upstream commit 6dfca831c03ef654b1f7bff1b8d487d330e9f76b ]
+
+Default rlimit RLIMIT_MEMLOCK is 64KB, causes bpf map failure.
+e.g.
+[root@lab bpf]#./xdp1 -N $(</sys/class/net/eth2/ifindex)
+failed to create a map: 1 Operation not permitted
+
+Fix it.
+
+Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
+Acked-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ samples/bpf/xdp1_user.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/samples/bpf/xdp1_user.c
++++ b/samples/bpf/xdp1_user.c
+@@ -14,6 +14,7 @@
+ #include <string.h>
+ #include <unistd.h>
+ #include <libgen.h>
++#include <sys/resource.h>
+
+ #include "bpf_load.h"
+ #include "bpf_util.h"
+@@ -69,6 +70,7 @@ static void usage(const char *prog)
+
+ int main(int argc, char **argv)
+ {
++ struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
+ const char *optstr = "SN";
+ char filename[256];
+ int opt;
+@@ -91,6 +93,12 @@ int main(int argc, char **argv)
+ usage(basename(argv[0]));
+ return 1;
+ }
++
++ if (setrlimit(RLIMIT_MEMLOCK, &r)) {
++ perror("setrlimit(RLIMIT_MEMLOCK)");
++ return 1;
++ }
++
+ ifindex = strtoul(argv[optind], NULL, 0);
+
+ snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 7 Nov 2017 11:46:05 +0100
+Subject: scsi: aacraid: use timespec64 instead of timeval
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+
+[ Upstream commit 820f188659122602ab217dd80cfa32b3ac0c55c0 ]
+
+aacraid passes the current time to the firmware in one of two ways,
+either as year/month/day/... or as 32-bit unsigned seconds.
+
+The first one is broken on 32-bit architectures as it cannot go past
+year 2038. Using timespec64 here makes it behave properly on both 32-bit
+and 64-bit architectures, and avoids relying on signed integer overflow
+to pass times into the second interface.
+
+The interface used in aac_send_hosttime() however is still problematic
+in year 2106 when 32-bit seconds overflow. Hopefully we don't have to
+worry about aacraid by that time.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/aacraid/commsup.c | 26 +++++++++++++-------------
+ 1 file changed, 13 insertions(+), 13 deletions(-)
+
+--- a/drivers/scsi/aacraid/commsup.c
++++ b/drivers/scsi/aacraid/commsup.c
+@@ -2383,19 +2383,19 @@ fib_free_out:
+ goto out;
+ }
+
+-int aac_send_safw_hostttime(struct aac_dev *dev, struct timeval *now)
++int aac_send_safw_hostttime(struct aac_dev *dev, struct timespec64 *now)
+ {
+ struct tm cur_tm;
+ char wellness_str[] = "<HW>TD\010\0\0\0\0\0\0\0\0\0DW\0\0ZZ";
+ u32 datasize = sizeof(wellness_str);
+- unsigned long local_time;
++ time64_t local_time;
+ int ret = -ENODEV;
+
+ if (!dev->sa_firmware)
+ goto out;
+
+- local_time = (u32)(now->tv_sec - (sys_tz.tz_minuteswest * 60));
+- time_to_tm(local_time, 0, &cur_tm);
++ local_time = (now->tv_sec - (sys_tz.tz_minuteswest * 60));
++ time64_to_tm(local_time, 0, &cur_tm);
+ cur_tm.tm_mon += 1;
+ cur_tm.tm_year += 1900;
+ wellness_str[8] = bin2bcd(cur_tm.tm_hour);
+@@ -2412,7 +2412,7 @@ out:
+ return ret;
+ }
+
+-int aac_send_hosttime(struct aac_dev *dev, struct timeval *now)
++int aac_send_hosttime(struct aac_dev *dev, struct timespec64 *now)
+ {
+ int ret = -ENOMEM;
+ struct fib *fibptr;
+@@ -2424,7 +2424,7 @@ int aac_send_hosttime(struct aac_dev *de
+
+ aac_fib_init(fibptr);
+ info = (__le32 *)fib_data(fibptr);
+- *info = cpu_to_le32(now->tv_sec);
++ *info = cpu_to_le32(now->tv_sec); /* overflow in y2106 */
+ ret = aac_fib_send(SendHostTime, fibptr, sizeof(*info), FsaNormal,
+ 1, 1, NULL, NULL);
+
+@@ -2496,7 +2496,7 @@ int aac_command_thread(void *data)
+ }
+ if (!time_before(next_check_jiffies,next_jiffies)
+ && ((difference = next_jiffies - jiffies) <= 0)) {
+- struct timeval now;
++ struct timespec64 now;
+ int ret;
+
+ /* Don't even try to talk to adapter if its sick */
+@@ -2506,15 +2506,15 @@ int aac_command_thread(void *data)
+ next_check_jiffies = jiffies
+ + ((long)(unsigned)check_interval)
+ * HZ;
+- do_gettimeofday(&now);
++ ktime_get_real_ts64(&now);
+
+ /* Synchronize our watches */
+- if (((1000000 - (1000000 / HZ)) > now.tv_usec)
+- && (now.tv_usec > (1000000 / HZ)))
+- difference = (((1000000 - now.tv_usec) * HZ)
+- + 500000) / 1000000;
++ if (((NSEC_PER_SEC - (NSEC_PER_SEC / HZ)) > now.tv_nsec)
++ && (now.tv_nsec > (NSEC_PER_SEC / HZ)))
++ difference = (((NSEC_PER_SEC - now.tv_nsec) * HZ)
++ + NSEC_PER_SEC / 2) / NSEC_PER_SEC;
+ else {
+- if (now.tv_usec > 500000)
++ if (now.tv_nsec > NSEC_PER_SEC / 2)
+ ++now.tv_sec;
+
+ if (dev->sa_firmware)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 4 Oct 2017 10:50:37 +0300
+Subject: scsi: bfa: integer overflow in debugfs
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+
+[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]
+
+We could allocate less memory than intended because we do:
+
+ bfad->regdata = kzalloc(len << 2, GFP_KERNEL);
+
+The shift can overflow leading to a crash. This is debugfs code so the
+impact is very small. I fixed the network version of this in March with
+commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").
+
+Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/bfa/bfad_debugfs.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/bfa/bfad_debugfs.c
++++ b/drivers/scsi/bfa/bfad_debugfs.c
+@@ -255,7 +255,8 @@ bfad_debugfs_write_regrd(struct file *fi
+ struct bfad_s *bfad = port->bfad;
+ struct bfa_s *bfa = &bfad->bfa;
+ struct bfa_ioc_s *ioc = &bfa->ioc;
+- int addr, len, rc, i;
++ int addr, rc, i;
++ u32 len;
+ u32 *regbuf;
+ void __iomem *rb, *reg_addr;
+ unsigned long flags;
+@@ -266,7 +267,7 @@ bfad_debugfs_write_regrd(struct file *fi
+ return PTR_ERR(kern_buf);
+
+ rc = sscanf(kern_buf, "%x:%x", &addr, &len);
+- if (rc < 2) {
++ if (rc < 2 || len > (UINT_MAX >> 2)) {
+ printk(KERN_INFO
+ "bfad[%d]: %s failed to read user buf\n",
+ bfad->inst_no, __func__);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Xiaofei Tan <tanxiaofei@huawei.com>
+Date: Tue, 24 Oct 2017 23:51:38 +0800
+Subject: scsi: hisi_sas: fix the risk of freeing slot twice
+
+From: Xiaofei Tan <tanxiaofei@huawei.com>
+
+
+[ Upstream commit 6ba0fbc35aa9f3bc8c12be3b4047055c9ce2ac92 ]
+
+The function hisi_sas_slot_task_free() is used to free the slot and do
+tidy-up of LLDD resources. The LLDD generally should know the state of
+a slot and decide when to free it, and it should only be done once.
+
+For some scenarios, we really don't know the state, like when TMF
+timeout. In this case, we check task->lldd_task before calling
+hisi_sas_slot_task_free().
+
+However, we may miss some scenarios when we should also check
+task->lldd_task, and it is not SMP safe to check task->lldd_task as we
+don't protect it within spin lock.
+
+This patch is to fix this risk of freeing slot twice, as follows:
+
+ 1. Check task->lldd_task in the hisi_sas_slot_task_free(), and give
+ up freeing of this time if task->lldd_task is NULL.
+
+ 2. Set slot->buf to NULL after it is freed.
+
+Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
+Signed-off-by: John Garry <john.garry@huawei.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/hisi_sas/hisi_sas_main.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
++++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
+@@ -185,13 +185,16 @@ void hisi_sas_slot_task_free(struct hisi
+ struct domain_device *device = task->dev;
+ struct hisi_sas_device *sas_dev = device->lldd_dev;
+
++ if (!task->lldd_task)
++ return;
++
++ task->lldd_task = NULL;
++
+ if (!sas_protocol_ata(task->task_proto))
+ if (slot->n_elem)
+ dma_unmap_sg(dev, task->scatter, slot->n_elem,
+ task->data_dir);
+
+- task->lldd_task = NULL;
+-
+ if (sas_dev)
+ atomic64_dec(&sas_dev->running_req);
+ }
+@@ -199,8 +202,8 @@ void hisi_sas_slot_task_free(struct hisi
+ if (slot->buf)
+ dma_pool_free(hisi_hba->buffer_pool, slot->buf, slot->buf_dma);
+
+-
+ list_del_init(&slot->entry);
++ slot->buf = NULL;
+ slot->task = NULL;
+ slot->port = NULL;
+ hisi_sas_slot_index_free(hisi_hba, slot->idx);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Martin Wilck <mwilck@suse.de>
+Date: Fri, 20 Oct 2017 16:51:14 -0500
+Subject: scsi: hpsa: cleanup sas_phy structures in sysfs when unloading
+
+From: Martin Wilck <mwilck@suse.de>
+
+
+[ Upstream commit 55ca38b4255bb336c2d35990bdb2b368e19b435a ]
+
+I am resubmitting this patch on behalf of Martin Wilck with his
+permission.
+
+The original patch can be found here:
+https://www.spinics.net/lists/linux-scsi/msg102083.html
+
+This patch did not help until Hannes's
+commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
+was applied to the kernel.
+
+--------------------------------------
+Original patch description from Martin:
+--------------------------------------
+
+When the hpsa module is unloaded using rmmod, dangling
+symlinks remain under /sys/class/sas_phy. Fix this by
+calling sas_phy_delete() rather than sas_phy_free (which,
+according to comments, should not be called for PHYs that
+have been set up successfully, anyway).
+
+Tested-by: Don Brace <don.brace@microsemi.com>
+Reviewed-by: Don Brace <don.brace@microsemi.com>
+Signed-off-by: Martin Wilck <mwilck@suse.de>
+Signed-off-by: Don Brace <don.brace@microsemi.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/hpsa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/hpsa.c
++++ b/drivers/scsi/hpsa.c
+@@ -9207,9 +9207,9 @@ static void hpsa_free_sas_phy(struct hps
+ struct sas_phy *phy = hpsa_sas_phy->phy;
+
+ sas_port_delete_phy(hpsa_sas_phy->parent_port->port, phy);
+- sas_phy_free(phy);
+ if (hpsa_sas_phy->added_to_port)
+ list_del(&hpsa_sas_phy->phy_list_entry);
++ sas_phy_delete(phy);
+ kfree(hpsa_sas_phy);
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Martin Wilck <mwilck@suse.de>
+Date: Fri, 20 Oct 2017 16:51:08 -0500
+Subject: scsi: hpsa: destroy sas transport properties before scsi_host
+
+From: Martin Wilck <mwilck@suse.de>
+
+
+[ Upstream commit dfb2e6f46b3074eb85203d8f0888b71ec1c2e37a ]
+
+This patch cleans up a lot of warnings when unloading the driver.
+
+A current example of the stack trace starts with:
+ [ 142.570715] sysfs group 'power' not found for kobject 'port-5:0'
+There can be hundreds of these messages during a driver unload.
+
+I am resubmitting this patch on behalf of Martin Wilck with his
+permission.
+
+His original patch can be found here:
+https://www.spinics.net/lists/linux-scsi/msg102085.html
+
+This patch did not help until Hannes's
+commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
+was applied to the kernel.
+
+---------------------------
+Original patch description:
+---------------------------
+
+Unloading the hpsa driver causes warnings
+
+[ 1063.793652] WARNING: CPU: 1 PID: 4850 at ../fs/sysfs/group.c:237 device_del+0x54/0x240()
+[ 1063.793659] sysfs group ffffffff81cf21a0 not found for kobject 'port-2:0'
+
+with two different stacks:
+1)
+[ 1063.793774] [<ffffffff81448af4>] device_del+0x54/0x240
+[ 1063.793780] [<ffffffff8145178a>] transport_remove_classdev+0x4a/0x60
+[ 1063.793784] [<ffffffff81451216>] attribute_container_device_trigger+0xa6/0xb0
+[ 1063.793802] [<ffffffffa0105d46>] sas_port_delete+0x126/0x160 [scsi_transport_sas]
+[ 1063.793819] [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa]
+
+2)
+[ 1063.797103] [<ffffffff81448af4>] device_del+0x54/0x240
+[ 1063.797118] [<ffffffffa0105d4e>] sas_port_delete+0x12e/0x160 [scsi_transport_sas]
+[ 1063.797134] [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa]
+
+This is caused by the fact that host device hostX is deleted before the
+SAS transport devices hostX/port-a:b.
+
+This patch fixes this by reverting the order of device deletions.
+
+Tested-by: Don Brace <don.brace@microsemi.com>
+Reviewed-by: Don Brace <don.brace@microsemi.com>
+Signed-off-by: Martin Wilck <mwilck@suse.de>
+Signed-off-by: Don Brace <don.brace@microsemi.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/hpsa.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/hpsa.c
++++ b/drivers/scsi/hpsa.c
+@@ -8684,6 +8684,8 @@ static void hpsa_remove_one(struct pci_d
+ destroy_workqueue(h->rescan_ctlr_wq);
+ destroy_workqueue(h->resubmit_wq);
+
++ hpsa_delete_sas_host(h);
++
+ /*
+ * Call before disabling interrupts.
+ * scsi_remove_host can trigger I/O operations especially
+@@ -8718,8 +8720,6 @@ static void hpsa_remove_one(struct pci_d
+ h->lockup_detected = NULL; /* init_one 2 */
+ /* (void) pci_disable_pcie_error_reporting(pdev); */ /* init_one 1 */
+
+- hpsa_delete_sas_host(h);
+-
+ kfree(h); /* init_one 1 */
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Douglas Gilbert <dgilbert@interlog.com>
+Date: Sun, 29 Oct 2017 10:47:19 -0400
+Subject: scsi: scsi_debug: write_same: fix error report
+
+From: Douglas Gilbert <dgilbert@interlog.com>
+
+
+[ Upstream commit e33d7c56450b0a5c7290cbf9e1581fab5174f552 ]
+
+The scsi_debug driver incorrectly suggests there is an error with the
+SCSI WRITE SAME command when the number_of_logical_blocks is greater
+than 1. It will also suggest there is an error when NDOB
+(no data-out buffer) is set and the number_of_logical_blocks is
+greater than 0. Both are valid, fix.
+
+Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/scsi_debug.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/scsi/scsi_debug.c
++++ b/drivers/scsi/scsi_debug.c
+@@ -3001,11 +3001,11 @@ static int resp_write_same(struct scsi_c
+ if (-1 == ret) {
+ write_unlock_irqrestore(&atomic_rw, iflags);
+ return DID_ERROR << 16;
+- } else if (sdebug_verbose && (ret < (num * sdebug_sector_size)))
++ } else if (sdebug_verbose && !ndob && (ret < sdebug_sector_size))
+ sdev_printk(KERN_INFO, scp->device,
+- "%s: %s: cdb indicated=%u, IO sent=%d bytes\n",
++ "%s: %s: lb size=%u, IO sent=%d bytes\n",
+ my_name, "write same",
+- num * sdebug_sector_size, ret);
++ sdebug_sector_size, ret);
+
+ /* Copy first sector to remaining blocks */
+ for (i = 1 ; i < num ; i++)
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Kurt Garloff <garloff@suse.de>
+Date: Tue, 17 Oct 2017 09:10:45 +0200
+Subject: scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
+
+From: Kurt Garloff <garloff@suse.de>
+
+
+[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]
+
+All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
+SCSI-2 for whatever reason.
+
+Signed-off-by: Kurt Garloff <garloff@suse.de>
+Signed-off-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/scsi_devinfo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/scsi_devinfo.c
++++ b/drivers/scsi/scsi_devinfo.c
+@@ -161,7 +161,7 @@ static struct {
+ {"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */
+ {"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */
+ {"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
+- {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN},
++ {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2},
+ {"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN},
+ {"easyRAID", "16P", NULL, BLIST_NOREPORTLUN},
+ {"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN},
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: weiping zhang <zhangweiping@didichuxing.com>
+Date: Thu, 12 Oct 2017 14:56:44 +0800
+Subject: scsi: sd: change allow_restart to bool in sysfs interface
+
+From: weiping zhang <zhangweiping@didichuxing.com>
+
+
+[ Upstream commit 658e9a6dc1126f21fa417cd213e1cdbff8be0ba2 ]
+
+/sys/class/scsi_disk/0:2:0:0/allow_restart can be changed to 0
+unexpectedly by writing an invalid string such as the following:
+
+echo asdf > /sys/class/scsi_disk/0:2:0:0/allow_restart
+
+Signed-off-by: weiping zhang <zhangweiping@didichuxing.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/sd.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -257,6 +257,7 @@ static ssize_t
+ allow_restart_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+ {
++ bool v;
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+ struct scsi_device *sdp = sdkp->device;
+
+@@ -266,7 +267,10 @@ allow_restart_store(struct device *dev,
+ if (sdp->type != TYPE_DISK && sdp->type != TYPE_ZBC)
+ return -EINVAL;
+
+- sdp->allow_restart = simple_strtoul(buf, NULL, 10);
++ if (kstrtobool(buf, &v))
++ return -EINVAL;
++
++ sdp->allow_restart = v;
+
+ return count;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: weiping zhang <zhangweiping@didichuxing.com>
+Date: Thu, 12 Oct 2017 14:57:06 +0800
+Subject: scsi: sd: change manage_start_stop to bool in sysfs interface
+
+From: weiping zhang <zhangweiping@didichuxing.com>
+
+
+[ Upstream commit 623401ee33e42cee64d333877892be8db02951eb ]
+
+/sys/class/scsi_disk/0:2:0:0/manage_start_stop can be changed to 0
+unexpectly by writing an invalid string.
+
+Signed-off-by: weiping zhang <zhangweiping@didichuxing.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/sd.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -231,11 +231,15 @@ manage_start_stop_store(struct device *d
+ {
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+ struct scsi_device *sdp = sdkp->device;
++ bool v;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
+- sdp->manage_start_stop = simple_strtoul(buf, NULL, 10);
++ if (kstrtobool(buf, &v))
++ return -EINVAL;
++
++ sdp->manage_start_stop = v;
+
+ return count;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 16 Oct 2017 15:06:19 +0200
+Subject: serdev: ttyport: enforce tty-driver open() requirement
+
+From: Johan Hovold <johan@kernel.org>
+
+
+[ Upstream commit dee7d0f3b200c67c6ee96bd37c6e8fa52690ab56 ]
+
+The tty-driver open routine is mandatory, but the serdev
+tty-port-controller implementation did not treat it as such and would
+instead fall back to calling tty_port_open() directly.
+
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serdev/serdev-ttyport.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/serdev/serdev-ttyport.c
++++ b/drivers/tty/serdev/serdev-ttyport.c
+@@ -120,10 +120,10 @@ static int ttyport_open(struct serdev_co
+ return PTR_ERR(tty);
+ serport->tty = tty;
+
+- if (tty->ops->open)
+- tty->ops->open(serport->tty, NULL);
+- else
+- tty_port_open(serport->port, tty, NULL);
++ if (!tty->ops->open)
++ goto err_unlock;
++
++ tty->ops->open(serport->tty, NULL);
+
+ /* Bring the UART into a known 8 bits no parity hw fc state */
+ ktermios = tty->termios;
+@@ -140,6 +140,12 @@ static int ttyport_open(struct serdev_co
+
+ tty_unlock(serport->tty);
+ return 0;
++
++err_unlock:
++ tty_unlock(tty);
++ tty_release_struct(tty, serport->tty_idx);
++
++ return -ENODEV;
+ }
+
+ static void ttyport_close(struct serdev_controller *ctrl)
ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
ext4-add-missing-error-check-in-__ext4_new_inode.patch
ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
+ib-mlx4-fix-rss-s-qpc-attributes-assignments.patch
+hid-cp2112-fix-broken-gpio_direction_input-callback.patch
+sfc-don-t-warn-on-successful-change-of-mac.patch
+fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
+video-udlfb-fix-read-edid-timeout.patch
+video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch
+video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch
+rtc-pcf8563-fix-output-clock-rate.patch
+scsi-aacraid-use-timespec64-instead-of-timeval.patch
+drm-amdgpu-bypass-lru-touch-for-kiq-ring-submission.patch
+pm-s2idle-clear-the-events_check_enabled-flag.patch
+asoc-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.patch
+dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
+mlxsw-spectrum-fix-error-return-code-in-mlxsw_sp_port_create.patch
+pci-pme-handle-invalid-data-when-reading-root-status.patch
+powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch
+pci-do-not-allocate-more-buses-than-available-in-parent.patch
+iommu-mediatek-fix-driver-name.patch
+thunderbolt-tb-fix-use-after-free-in-tb_activate_pcie_devices.patch
+netfilter-ipvs-fix-inappropriate-output-of-procfs.patch
+powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch
+powerpc-ipic-fix-status-get-and-status-clear.patch
+powerpc-pseries-vio-dispose-of-virq-mapping-on-vdevice-unregister.patch
+platform-x86-intel_punit_ipc-fix-resource-ioremap-warning.patch
+platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch
+target-iscsi-detect-conn_cmd_list-corruption-early.patch
+target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
+iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
+target-fix-condition-return-in-core_pr_dump_initiator_port.patch
+target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
+badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch
+iommu-amd-limit-the-iova-page-range-to-the-specified-addresses.patch
+xfs-truncate-pagecache-before-writeback-in-xfs_setattr_size.patch
+arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch
+crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
+mm-handle-0-flags-in-_calc_vm_trans-macro.patch
+net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
+net-hns3-fix-a-misuse-to-devm_free_irq.patch
+staging-rtl8188eu-revert-part-of-staging-rtl8188eu-fix-comments-with-lines-over-80-characters.patch
+clk-mediatek-add-the-option-for-determining-pll-source-clock.patch
+clk-imx-imx7d-fix-parent-clock-for-ocram_clk.patch
+clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch
+media-camss-vfe-always-initialize-reg-at-vfe_set_xbar_cfg.patch
+clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch
+blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.patch
+clk-tegra-use-readl_relaxed_poll_timeout_atomic-in-tegra210_clock_init.patch
+clk-tegra-fix-cclk_lp-divisor-register.patch
+ppp-destroy-the-mutex-when-cleanup.patch
+asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch
+thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch
+misc-pci_endpoint_test-fix-failure-path-return-values-in-probe.patch
+misc-pci_endpoint_test-avoid-triggering-a-bug.patch
+scsi-scsi_debug-write_same-fix-error-report.patch
+gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch
+media-usbtv-fix-brightness-and-contrast-controls.patch
+rpmsg-glink-initialize-the-intent_req_comp-completion-variable.patch
+bcache-explicitly-destroy-mutex-while-exiting.patch
+bcache-fix-wrong-cache_misses-statistics.patch
+ib-hfi1-return-actual-operational-vls-in-port-info-query.patch
+bluetooth-hci_ldisc-fix-another-race-when-closing-the-tty.patch
+arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch
+btrfs-fix-false-eio-for-missing-device.patch
+btrfs-explicitly-handle-btrfs_update_root-failure.patch
+btrfs-undo-writable-superblocke-when-sprouting-fails.patch
+btrfs-avoid-null-pointer-dereference-on-fs_info-when-calling-btrfs_crit.patch
+btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch
+qtnfmac-modify-full-tx-queue-error-reporting.patch
+mtd-spi-nor-stm32-quadspi-fix-uninitialized-error-return-code.patch
+arm64-dts-meson-gxbb-odroidc2-fix-usb1-power-supply.patch
+bluetooth-btusb-add-new-nfa344a-entry.patch
+samples-bpf-adjust-rlimit-rlimit_memlock-for-xdp1.patch
+liquidio-fix-kernel-panic-in-vf-driver.patch
+platform-x86-hp_accel-add-quirk-for-hp-probook-440-g4.patch
+nvme-use-kref_get_unless_zero-in-nvme_find_get_ns.patch
+l2tp-cleanup-l2tp_tunnel_delete-calls.patch
+xfs-fix-log-block-underflow-during-recovery-cycle-verification.patch
+xfs-return-a-distinct-error-code-value-for-iget_incore-cache-misses.patch
+xfs-fix-incorrect-extent-state-in-xfs_bmap_add_extent_unwritten_real.patch
+net-dsa-lan9303-do-not-disable-switch-fabric-port-0-at-.probe.patch
+net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
+net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
+net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
+rdma-cxgb4-declare-stag-as-__be32.patch
+pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch
+scsi-hisi_sas-fix-the-risk-of-freeing-slot-twice.patch
+scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch
+scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch
+mfd-mxs-lradc-fix-error-handling-in-mxs_lradc_probe.patch
+net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
+net-hns3-fix-the-bug-when-map-buffer-fail.patch
+net-hns3-fix-a-bug-when-alloc-new-buffer.patch
+serdev-ttyport-enforce-tty-driver-open-requirement.patch
+powerpc-perf-hv-24x7-fix-incorrect-comparison-in-memord.patch
+powerpc-xmon-check-before-calling-xive-functions.patch
+soc-mediatek-pwrap-fix-compiler-errors.patch
+ipv4-ipv4_default_advmss-should-use-route-mtu.patch
+kvm-nvmx-fix-ept-switching-advertising.patch
+tty-fix-oops-when-rmmod-8250.patch
+dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
+dev-dax-fix-uninitialized-variable-build-warning.patch
+pinctrl-adi2-fix-kconfig-build-problem.patch
+raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
+scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
+ib-core-fix-use-workqueue-without-wq_mem_reclaim.patch
+ib-core-fix-calculation-of-maximum-roce-mtu.patch
+vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch
+ib-hfi1-mask-out-a-bit-from-psn-trace.patch
+rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_createbss_cmd.patch
+rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_disassoc_cmd.patch
+ipmi_si-fix-memory-leak-on-new_smi.patch
+nullb-fix-error-return-code-in-null_init.patch
+scsi-sd-change-manage_start_stop-to-bool-in-sysfs-interface.patch
+scsi-sd-change-allow_restart-to-bool-in-sysfs-interface.patch
+scsi-bfa-integer-overflow-in-debugfs.patch
+raid5-ppl-check-recovery_offset-when-performing-ppl-recovery.patch
+md-cluster-fix-wrong-condition-check-in-raid1_write_request.patch
+xprtrdma-don-t-defer-fencing-an-async-rpc-s-chunks.patch
+udf-avoid-overflow-when-session-starts-at-large-offset.patch
+macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch
+ib-core-fix-endianness-annotation-in-rdma_is_multicast_addr.patch
+rdma-cma-avoid-triggering-undefined-behavior.patch
+ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.patch
+icmp-don-t-fail-on-fragment-reassembly-time-exceeded.patch
+lightnvm-pblk-prevent-gc-kicks-when-gc-is-not-operational.patch
+lightnvm-pblk-fix-changing-gc-group-list-for-a-line.patch
+lightnvm-pblk-use-right-flag-for-gc-allocation.patch
+lightnvm-pblk-initialize-debug-stat-counter.patch
+lightnvm-pblk-fix-min-size-for-page-mempool.patch
+lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
+ath9k-fix-tx99-potential-info-leak.patch
+ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch
+ath10k-fix-build-errors-with-config_pm.patch
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Robert Stonehouse <rstonehouse@solarflare.com>
+Date: Tue, 7 Nov 2017 17:30:30 +0000
+Subject: sfc: don't warn on successful change of MAC
+
+From: Robert Stonehouse <rstonehouse@solarflare.com>
+
+
+[ Upstream commit cbad52e92ad7f01f0be4ca58bde59462dc1afe3a ]
+
+Fixes: 535a61777f44e ("sfc: suppress handled MCDI failures when changing the MAC address")
+Signed-off-by: Bert Kenward <bkenward@solarflare.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/sfc/ef10.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/sfc/ef10.c
++++ b/drivers/net/ethernet/sfc/ef10.c
+@@ -5726,7 +5726,7 @@ static int efx_ef10_set_mac_address(stru
+ * MCFW do not support VFs.
+ */
+ rc = efx_ef10_vport_set_mac_address(efx);
+- } else {
++ } else if (rc) {
+ efx_mcdi_display_error(efx, MC_CMD_VADAPTOR_SET_MAC,
+ sizeof(inbuf), NULL, 0, rc);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Matthias Brugger <matthias.bgg@gmail.com>
+Date: Sat, 21 Oct 2017 10:17:47 +0200
+Subject: soc: mediatek: pwrap: fix compiler errors
+
+From: Matthias Brugger <matthias.bgg@gmail.com>
+
+
+[ Upstream commit fb2c1934f30577756e55e24e8870b45c78da3bc2 ]
+
+When compiling using sparse, we got the following error:
+drivers/soc/mediatek/mtk-pmic-wrap.c:686:25: error: dubious one-bit signed bitfield
+
+Changing the data type to unsigned fixes this.
+
+Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
++++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
+@@ -522,7 +522,7 @@ struct pmic_wrapper_type {
+ u32 int_en_all;
+ u32 spi_w;
+ u32 wdt_src;
+- int has_bridge:1;
++ unsigned int has_bridge:1;
+ int (*init_reg_clock)(struct pmic_wrapper *wrp);
+ int (*init_soc_specific)(struct pmic_wrapper *wrp);
+ };
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Thu, 2 Nov 2017 10:30:11 +0100
+Subject: staging: rtl8188eu: Revert part of "staging: rtl8188eu: fix comments with lines over 80 characters"
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+
+[ Upstream commit 4004a9870bbefdb6644c3d2033f5315920a3b669 ]
+
+Commit 74e1e498e84e ("staging: rtl8188eu: fix comments with lines over 80
+characters") not only changed comments but also changed an if check:
+
+-if (pmlmepriv->cur_network.join_res != true) {
++if (!(pmlmepriv->cur_network.join_res)) {
+
+This is not equivalent as join_res is an int and can have values such
+as -2 and -3.
+
+Note for the next time, please only make one type of changes in a single
+clean-up commit.
+
+Fixes: 74e1e498e84e ("staging: rtl8188eu: fix comments with lines over 80 ...")
+Cc: Juliana Rodrigues <juliana.orod@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
++++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
+@@ -754,7 +754,7 @@ static void start_bss_network(struct ada
+ }
+
+ /* setting only at first time */
+- if (!(pmlmepriv->cur_network.join_res)) {
++ if (pmlmepriv->cur_network.join_res != true) {
+ /* WEP Key will be set before this function, do not
+ * clear CAM.
+ */
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Jiang Yi <jiangyilism@gmail.com>
+Date: Fri, 11 Aug 2017 11:29:44 +0800
+Subject: target/file: Do not return error for UNMAP if length is zero
+
+From: Jiang Yi <jiangyilism@gmail.com>
+
+
+[ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ]
+
+The function fd_execute_unmap() in target_core_file.c calles
+
+ret = file->f_op->fallocate(file, mode, pos, len);
+
+Some filesystems implement fallocate() to return error if
+length is zero (e.g. btrfs) but according to SCSI Block
+Commands spec UNMAP should return success for zero length.
+
+Signed-off-by: Jiang Yi <jiangyilism@gmail.com>
+Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/target/target_core_file.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/target/target_core_file.c
++++ b/drivers/target/target_core_file.c
+@@ -482,6 +482,10 @@ fd_execute_unmap(struct se_cmd *cmd, sec
+ struct inode *inode = file->f_mapping->host;
+ int ret;
+
++ if (!nolb) {
++ return 0;
++ }
++
+ if (cmd->se_dev->dev_attrib.pi_prot_type) {
+ ret = fd_do_prot_unmap(cmd, lba, nolb);
+ if (ret)
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: tangwenji <tang.wenji@zte.com.cn>
+Date: Thu, 24 Aug 2017 19:59:37 +0800
+Subject: target:fix condition return in core_pr_dump_initiator_port()
+
+From: tangwenji <tang.wenji@zte.com.cn>
+
+
+[ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ]
+
+When is pr_reg->isid_present_at_reg is false,this function should return.
+
+This fixes a regression originally introduced by:
+
+ commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5
+ Author: Andy Grover <agrover@redhat.com>
+ Date: Thu May 16 10:40:55 2013 -0700
+
+ target: Alter core_pr_dump_initiator_port for ease of use
+
+Signed-off-by: tangwenji <tang.wenji@zte.com.cn>
+Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/target/target_core_pr.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/target/target_core_pr.c
++++ b/drivers/target/target_core_pr.c
+@@ -58,8 +58,10 @@ void core_pr_dump_initiator_port(
+ char *buf,
+ u32 size)
+ {
+- if (!pr_reg->isid_present_at_reg)
++ if (!pr_reg->isid_present_at_reg) {
+ buf[0] = '\0';
++ return;
++ }
+
+ snprintf(buf, size, ",i,0x%s", pr_reg->pr_reg_isid);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Bart Van Assche <bart.vanassche@wdc.com>
+Date: Tue, 31 Oct 2017 11:03:18 -0700
+Subject: target/iscsi: Detect conn_cmd_list corruption early
+
+From: Bart Van Assche <bart.vanassche@wdc.com>
+
+
+[ Upstream commit 6eaf69e4ec075f5af236c0c89f75639a195db904 ]
+
+Certain behavior of the initiator can cause the target driver to
+send both a reject and a SCSI response. If that happens two
+target_put_sess_cmd() calls will occur without the command having
+been removed from conn_cmd_list. In other words, conn_cmd_list
+will get corrupted once the freed memory is reused. Although the
+Linux kernel can detect list corruption if list debugging is
+enabled, in this case the context in which list corruption is
+detected is not related to the context that caused list corruption.
+Hence add WARN_ON() statements that report the context that is
+causing list corruption.
+
+Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Mike Christie <mchristi@redhat.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/target/iscsi/iscsi_target_util.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/target/iscsi/iscsi_target_util.c
++++ b/drivers/target/iscsi/iscsi_target_util.c
+@@ -694,6 +694,8 @@ void iscsit_release_cmd(struct iscsi_cmd
+ struct iscsi_session *sess;
+ struct se_cmd *se_cmd = &cmd->se_cmd;
+
++ WARN_ON(!list_empty(&cmd->i_conn_node));
++
+ if (cmd->conn)
+ sess = cmd->conn->sess;
+ else
+@@ -716,6 +718,8 @@ void __iscsit_free_cmd(struct iscsi_cmd
+ {
+ struct iscsi_conn *conn = cmd->conn;
+
++ WARN_ON(!list_empty(&cmd->i_conn_node));
++
+ if (cmd->data_direction == DMA_TO_DEVICE) {
+ iscsit_stop_dataout_timer(cmd);
+ iscsit_free_r2ts_from_list(cmd);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Bart Van Assche <bart.vanassche@wdc.com>
+Date: Tue, 31 Oct 2017 11:03:17 -0700
+Subject: target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
+
+From: Bart Van Assche <bart.vanassche@wdc.com>
+
+
+[ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ]
+
+Avoid that cmd->se_cmd.se_tfo is read after a command has already been
+freed.
+
+Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Mike Christie <mchristi@redhat.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/target/iscsi/iscsi_target.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/target/iscsi/iscsi_target.c
++++ b/drivers/target/iscsi/iscsi_target.c
+@@ -834,6 +834,7 @@ static int iscsit_add_reject_from_cmd(
+ unsigned char *buf)
+ {
+ struct iscsi_conn *conn;
++ const bool do_put = cmd->se_cmd.se_tfo != NULL;
+
+ if (!cmd->conn) {
+ pr_err("cmd->conn is NULL for ITT: 0x%08x\n",
+@@ -864,7 +865,7 @@ static int iscsit_add_reject_from_cmd(
+ * Perform the kref_put now if se_cmd has already been setup by
+ * scsit_setup_scsi_cmd()
+ */
+- if (cmd->se_cmd.se_tfo != NULL) {
++ if (do_put) {
+ pr_debug("iscsi reject: calling target_put_sess_cmd >>>>>>\n");
+ target_put_sess_cmd(&cmd->se_cmd);
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Daniel Lezcano <daniel.lezcano@linaro.org>
+Date: Thu, 19 Oct 2017 19:05:58 +0200
+Subject: thermal/drivers/step_wise: Fix temperature regulation misbehavior
+
+From: Daniel Lezcano <daniel.lezcano@linaro.org>
+
+
+[ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ]
+
+There is a particular situation when the cooling device is cpufreq and the heat
+dissipation is not efficient enough where the temperature increases little by
+little until reaching the critical threshold and leading to a SoC reset.
+
+The behavior is reproducible on a hikey6220 with bad heat dissipation (eg.
+stacked with other boards).
+
+Running a simple C program doing while(1); for each CPU of the SoC makes the
+temperature to reach the passive regulation trip point and ends up to the
+maximum allowed temperature followed by a reset.
+
+This issue has been also reported by running the libhugetlbfs test suite.
+
+What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz
+while the temperature continues to grow.
+
+It appears the step wise governor calls get_target_state() the first time with
+the throttle set to true and the trend to 'raising'. The code selects logically
+the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so
+good. The temperature decreases immediately but still stays greater than the
+trip point, then get_target_state() is called again, this time with the
+throttle set to true *and* the trend to 'dropping'. From there the algorithm
+assumes we have to step down the state and the cpu frequency jumps back to
+1.2GHz. But the temperature is still higher than the trip point, so
+get_target_state() is called with throttle=1 and trend='raising' again, we jump
+to 900MHz, then get_target_state() is called with throttle=1 and
+trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not
+stabilizes and continues to increase.
+
+[ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
+[ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
+[ 237.922690] thermal cooling_device0: cur_state=0
+[ 237.922701] thermal cooling_device0: old_target=0, target=1
+[ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
+[ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
+[ 238.026694] thermal cooling_device0: cur_state=1
+[ 238.026707] thermal cooling_device0: old_target=1, target=0
+[ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
+[ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
+[ 238.134679] thermal cooling_device0: cur_state=0
+[ 238.134690] thermal cooling_device0: old_target=0, target=1
+
+In this situation the temperature continues to increase while the trend is
+oscillating between 'dropping' and 'raising'. We need to keep the current state
+untouched if the throttle is set, so the temperature can decrease or a higher
+state could be selected, thus preventing this oscillation.
+
+Keeping the next_target untouched when 'throttle' is true at 'dropping' time
+fixes the issue.
+
+The following traces show the governor does not change the next state if
+trend==2 (dropping) and throttle==1.
+
+[ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
+[ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
+[ 2306.128021] thermal cooling_device0: cur_state=0
+[ 2306.128031] thermal cooling_device0: old_target=0, target=1
+[ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
+[ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
+[ 2306.232030] thermal cooling_device0: cur_state=1
+[ 2306.232042] thermal cooling_device0: old_target=1, target=1
+[ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
+[ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1
+[ 2306.336021] thermal cooling_device0: cur_state=1
+[ 2306.336034] thermal cooling_device0: old_target=1, target=1
+[ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
+[ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
+[ 2306.440022] thermal cooling_device0: cur_state=1
+[ 2306.440034] thermal cooling_device0: old_target=1, target=0
+
+[ ... ]
+
+After a while, if the temperature continues to increase, the next state becomes
+2 which is 720MHz on the hikey. That results in the temperature stabilizing
+around the trip point.
+
+[ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
+[ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0
+[ 2455.832019] thermal cooling_device0: cur_state=1
+[ 2455.832032] thermal cooling_device0: old_target=1, target=1
+[ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
+[ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
+[ 2455.936027] thermal cooling_device0: cur_state=1
+[ 2455.936040] thermal cooling_device0: old_target=1, target=1
+[ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
+[ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
+[ 2456.044023] thermal cooling_device0: cur_state=1
+[ 2456.044036] thermal cooling_device0: old_target=1, target=1
+[ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
+[ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
+[ 2456.148042] thermal cooling_device0: cur_state=1
+[ 2456.148055] thermal cooling_device0: old_target=1, target=2
+[ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
+[ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
+[ 2456.252058] thermal cooling_device0: cur_state=2
+[ 2456.252075] thermal cooling_device0: old_target=2, target=1
+
+IOW, this change is needed to keep the state for a cooling device if the
+temperature trend is oscillating while the temperature increases slightly.
+
+Without this change, the situation above leads to a catastrophic crash by a
+hardware reset on hikey. This issue has been reported to happen on an OMAP
+dra7xx also.
+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Cc: Keerthy <j-keerthy@ti.com>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Leo Yan <leo.yan@linaro.org>
+Tested-by: Keerthy <j-keerthy@ti.com>
+Reviewed-by: Keerthy <j-keerthy@ti.com>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thermal/step_wise.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/drivers/thermal/step_wise.c
++++ b/drivers/thermal/step_wise.c
+@@ -31,8 +31,7 @@
+ * If the temperature is higher than a trip point,
+ * a. if the trend is THERMAL_TREND_RAISING, use higher cooling
+ * state for this trip point
+- * b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
+- * state for this trip point
++ * b. if the trend is THERMAL_TREND_DROPPING, do nothing
+ * c. if the trend is THERMAL_TREND_RAISE_FULL, use upper limit
+ * for this trip point
+ * d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit
+@@ -94,9 +93,11 @@ static unsigned long get_target_state(st
+ if (!throttle)
+ next_target = THERMAL_NO_TARGET;
+ } else {
+- next_target = cur_state - 1;
+- if (next_target > instance->upper)
+- next_target = instance->upper;
++ if (!throttle) {
++ next_target = cur_state - 1;
++ if (next_target > instance->upper)
++ next_target = instance->upper;
++ }
+ }
+ break;
+ case THERMAL_TREND_DROP_FULL:
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
+Date: Sat, 4 Nov 2017 23:52:54 -0500
+Subject: thunderbolt: tb: fix use after free in tb_activate_pcie_devices
+
+From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
+
+
+[ Upstream commit a2e373438f72391493a4425efc1b82030b6b4fd5 ]
+
+Add a ̣̣continue statement in order to avoid using a previously
+free'd pointer tunnel in list_add.
+
+Addresses-Coverity-ID: 1415336
+Fixes: 9d3cce0b6136 ("thunderbolt: Introduce thunderbolt bus and connection manager")
+Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/tb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/thunderbolt/tb.c
++++ b/drivers/thunderbolt/tb.c
+@@ -225,6 +225,7 @@ static void tb_activate_pcie_devices(str
+ tb_port_info(up_port,
+ "PCIe tunnel activation failed, aborting\n");
+ tb_pci_free(tunnel);
++ continue;
+ }
+
+ list_add(&tunnel->list, &tcm->tunnel_list);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: nixiaoming <nixiaoming@huawei.com>
+Date: Fri, 15 Sep 2017 17:45:56 +0800
+Subject: tty fix oops when rmmod 8250
+
+From: nixiaoming <nixiaoming@huawei.com>
+
+
+[ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ]
+
+After rmmod 8250.ko
+tty_kref_put starts kwork (release_one_tty) to release proc interface
+oops when accessing driver->driver_name in proc_tty_unregister_driver
+
+Use jprobe, found driver->driver_name point to 8250.ko
+static static struct uart_driver serial8250_reg
+.driver_name= serial,
+
+Use name in proc_dir_entry instead of driver->driver_name to fix oops
+
+test on linux 4.1.12:
+
+BUG: unable to handle kernel paging request at ffffffffa01979de
+IP: [<ffffffff81310f40>] strchr+0x0/0x30
+PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
+Oops: 0000 [#1] PREEMPT SMP
+Modules linked in: ... ... [last unloaded: 8250]
+CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1
+Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015
+Workqueue: events release_one_tty
+task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000
+RIP: 0010:[<ffffffff81310f40>] [<ffffffff81310f40>] strchr+0x0/0x30
+RSP: 0018:ffff880852887c90 EFLAGS: 00010282
+RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004
+RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de
+RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0
+R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de
+R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840
+FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0
+Stack:
+ ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2
+ ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010
+ ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08
+Call Trace:
+ [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0
+ [<ffffffff812354f0>] remove_proc_entry+0x40/0x180
+ [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60
+ [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0
+ [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40
+ [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0
+ [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20
+ [<ffffffff813becca>] release_one_tty+0x5a/0xd0
+ [<ffffffff81074159>] process_one_work+0x139/0x420
+ [<ffffffff810745a1>] worker_thread+0x121/0x450
+ [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40
+ [<ffffffff8107a16c>] kthread+0xec/0x110
+ [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220
+ [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
+ [<ffffffff815f7292>] ret_from_fork+0x42/0x70
+ [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
+
+Signed-off-by: nixiaoming <nixiaoming@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/proc/proc_tty.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/proc/proc_tty.c
++++ b/fs/proc/proc_tty.c
+@@ -15,6 +15,7 @@
+ #include <linux/tty.h>
+ #include <linux/seq_file.h>
+ #include <linux/bitops.h>
++#include "internal.h"
+
+ /*
+ * The /proc/tty directory inodes...
+@@ -165,7 +166,7 @@ void proc_tty_unregister_driver(struct t
+ if (!ent)
+ return;
+
+- remove_proc_entry(driver->driver_name, proc_tty_driver);
++ remove_proc_entry(ent->name, proc_tty_driver);
+
+ driver->proc_entry = NULL;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 16 Oct 2017 11:38:11 +0200
+Subject: udf: Avoid overflow when session starts at large offset
+
+From: Jan Kara <jack@suse.cz>
+
+
+[ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ]
+
+When session starts beyond offset 2^31 the arithmetics in
+udf_check_vsd() would overflow. Make sure the computation is done in
+large enough type.
+
+Reported-by: Cezary Sliwa <sliwa@ifpan.edu.pl>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/udf/super.c
++++ b/fs/udf/super.c
+@@ -703,7 +703,7 @@ static loff_t udf_check_vsd(struct super
+ else
+ sectorsize = sb->s_blocksize;
+
+- sector += (sbi->s_session << sb->s_blocksize_bits);
++ sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits);
+
+ udf_debug("Starting at sector %u (%ld byte sectors)\n",
+ (unsigned int)(sector >> sb->s_blocksize_bits),
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Thu, 9 Nov 2017 18:09:28 +0100
+Subject: video: fbdev: au1200fb: Release some resources if a memory allocation fails
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+
+[ Upstream commit 451f130602619a17c8883dd0b71b11624faffd51 ]
+
+We should go through the error handling code instead of returning -ENOMEM
+directly.
+
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Cc: Tejun Heo <tj@kernel.org>
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/au1200fb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/au1200fb.c
++++ b/drivers/video/fbdev/au1200fb.c
+@@ -1701,7 +1701,8 @@ static int au1200fb_drv_probe(struct pla
+ if (!fbdev->fb_mem) {
+ print_err("fail to allocate frambuffer (size: %dK))",
+ fbdev->fb_len / 1024);
+- return -ENOMEM;
++ ret = -ENOMEM;
++ goto failed;
+ }
+
+ /*
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Thu, 9 Nov 2017 18:09:28 +0100
+Subject: video: fbdev: au1200fb: Return an error code if a memory allocation fails
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+
+[ Upstream commit 8cae353e6b01ac3f18097f631cdbceb5ff28c7f3 ]
+
+'ret' is known to be 0 at this point.
+In case of memory allocation error in 'framebuffer_alloc()', return
+-ENOMEM instead.
+
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Cc: Tejun Heo <tj@kernel.org>
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/au1200fb.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/au1200fb.c
++++ b/drivers/video/fbdev/au1200fb.c
+@@ -1681,8 +1681,10 @@ static int au1200fb_drv_probe(struct pla
+
+ fbi = framebuffer_alloc(sizeof(struct au1200fb_device),
+ &dev->dev);
+- if (!fbi)
++ if (!fbi) {
++ ret = -ENOMEM;
+ goto failed;
++ }
+
+ _au1200fb_infos[plane] = fbi;
+ fbdev = fbi->par;
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Ladislav Michl <ladis@linux-mips.org>
+Date: Thu, 9 Nov 2017 18:09:30 +0100
+Subject: video: udlfb: Fix read EDID timeout
+
+From: Ladislav Michl <ladis@linux-mips.org>
+
+
+[ Upstream commit c98769475575c8a585f5b3952f4b5f90266f699b ]
+
+While usb_control_msg function expects timeout in miliseconds, a value
+of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error
+message which looks like:
+udlfb: Read EDID byte 78 failed err ffffff92
+as error is either negative errno or number of bytes transferred use %d
+format specifier.
+
+Returned EDID is in second byte, so return error when less than two bytes
+are received.
+
+Fixes: 18dffdf8913a ("staging: udlfb: enhance EDID and mode handling support")
+Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
+Cc: Bernie Thompson <bernie@plugable.com>
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/udlfb.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/video/fbdev/udlfb.c
++++ b/drivers/video/fbdev/udlfb.c
+@@ -769,11 +769,11 @@ static int dlfb_get_edid(struct dlfb_dat
+
+ for (i = 0; i < len; i++) {
+ ret = usb_control_msg(dev->udev,
+- usb_rcvctrlpipe(dev->udev, 0), (0x02),
+- (0x80 | (0x02 << 5)), i << 8, 0xA1, rbuf, 2,
+- HZ);
+- if (ret < 1) {
+- pr_err("Read EDID byte %d failed err %x\n", i, ret);
++ usb_rcvctrlpipe(dev->udev, 0), 0x02,
++ (0x80 | (0x02 << 5)), i << 8, 0xA1,
++ rbuf, 2, USB_CTRL_GET_TIMEOUT);
++ if (ret < 2) {
++ pr_err("Read EDID byte %d failed: %d\n", i, ret);
+ i--;
+ break;
+ }
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Jia-Ju Bai <baijiaju1990@163.com>
+Date: Mon, 9 Oct 2017 16:45:55 +0800
+Subject: vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend
+
+From: Jia-Ju Bai <baijiaju1990@163.com>
+
+
+[ Upstream commit 42c8eb3f6e15367981b274cb79ee4657e2c6949d ]
+
+The driver may sleep under a spinlock, and the function call path is:
+vt6655_suspend (acquire the spinlock)
+ pci_set_power_state
+ __pci_start_power_transition (drivers/pci/pci.c)
+ msleep --> may sleep
+
+To fix it, pci_set_power_state is called without having a spinlock.
+
+This bug is found by my static analysis tool and my code review.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/vt6655/device_main.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/vt6655/device_main.c
++++ b/drivers/staging/vt6655/device_main.c
+@@ -1693,10 +1693,11 @@ static int vt6655_suspend(struct pci_dev
+ MACbShutdown(priv);
+
+ pci_disable_device(pcid);
+- pci_set_power_state(pcid, pci_choose_state(pcid, state));
+
+ spin_unlock_irqrestore(&priv->lock, flags);
+
++ pci_set_power_state(pcid, pci_choose_state(pcid, state));
++
+ return 0;
+ }
+
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Christoph Hellwig <hch@lst.de>
+Date: Tue, 17 Oct 2017 14:16:19 -0700
+Subject: xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real
+
+From: Christoph Hellwig <hch@lst.de>
+
+
+[ Upstream commit 5e422f5e4fd71d18bc6b851eeb3864477b3d842e ]
+
+There was one spot in xfs_bmap_add_extent_unwritten_real that didn't use the
+passed in new extent state but always converted to normal, leading to wrong
+behavior when converting from normal to unwritten.
+
+Only found by code inspection, it seems like this code path to move partial
+extent from written to unwritten while merging it with the next extent is
+rarely exercised.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/libxfs/xfs_bmap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/xfs/libxfs/xfs_bmap.c
++++ b/fs/xfs/libxfs/xfs_bmap.c
+@@ -2560,7 +2560,7 @@ xfs_bmap_add_extent_unwritten_real(
+ &i)))
+ goto done;
+ XFS_WANT_CORRUPTED_GOTO(mp, i == 0, done);
+- cur->bc_rec.b.br_state = XFS_EXT_NORM;
++ cur->bc_rec.b.br_state = new->br_state;
+ if ((error = xfs_btree_insert(cur, &i)))
+ goto done;
+ XFS_WANT_CORRUPTED_GOTO(mp, i == 1, done);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Brian Foster <bfoster@redhat.com>
+Date: Thu, 26 Oct 2017 09:31:16 -0700
+Subject: xfs: fix log block underflow during recovery cycle verification
+
+From: Brian Foster <bfoster@redhat.com>
+
+
+[ Upstream commit 9f2a4505800607e537e9dd9dea4f55c4b0c30c7a ]
+
+It is possible for mkfs to format very small filesystems with too
+small of an internal log with respect to the various minimum size
+and block count requirements. If this occurs when the log happens to
+be smaller than the scan window used for cycle verification and the
+scan wraps the end of the log, the start_blk calculation in
+xlog_find_head() underflows and leads to an attempt to scan an
+invalid range of log blocks. This results in log recovery failure
+and a failed mount.
+
+Since there may be filesystems out in the wild with this kind of
+geometry, we cannot simply refuse to mount. Instead, cap the scan
+window for cycle verification to the size of the physical log. This
+ensures that the cycle verification proceeds as expected when the
+scan wraps the end of the log.
+
+Reported-by: Zorro Lang <zlang@redhat.com>
+Signed-off-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_log_recover.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/xfs/xfs_log_recover.c
++++ b/fs/xfs/xfs_log_recover.c
+@@ -753,7 +753,7 @@ xlog_find_head(
+ * in the in-core log. The following number can be made tighter if
+ * we actually look at the block size of the filesystem.
+ */
+- num_scan_bblks = XLOG_TOTAL_REC_SHIFT(log);
++ num_scan_bblks = min_t(int, log_bbnum, XLOG_TOTAL_REC_SHIFT(log));
+ if (head_blk >= num_scan_bblks) {
+ /*
+ * We are guaranteed that the entire check can be performed
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: "Darrick J. Wong" <darrick.wong@oracle.com>
+Date: Tue, 17 Oct 2017 21:37:32 -0700
+Subject: xfs: return a distinct error code value for IGET_INCORE cache misses
+
+From: "Darrick J. Wong" <darrick.wong@oracle.com>
+
+
+[ Upstream commit ed438b476b611c67089760037139f93ea8ed41d5 ]
+
+For an XFS_IGET_INCORE iget operation, if the inode isn't in the cache,
+return ENODATA so that we don't confuse it with the pre-existing ENOENT
+cases (inode is in cache, but freed).
+
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Dave Chinner <dchinner@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_icache.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/xfs/xfs_icache.c
++++ b/fs/xfs/xfs_icache.c
+@@ -610,7 +610,7 @@ again:
+ } else {
+ rcu_read_unlock();
+ if (flags & XFS_IGET_INCORE) {
+- error = -ENOENT;
++ error = -ENODATA;
+ goto out_error_or_again;
+ }
+ XFS_STATS_INC(mp, xs_ig_missed);
--- /dev/null
+From foo@baz Mon Dec 18 13:28:59 CET 2017
+From: Eryu Guan <eguan@redhat.com>
+Date: Wed, 1 Nov 2017 21:43:50 -0700
+Subject: xfs: truncate pagecache before writeback in xfs_setattr_size()
+
+From: Eryu Guan <eguan@redhat.com>
+
+
+[ Upstream commit 350976ae21873b0d36584ea005076356431b8f79 ]
+
+On truncate down, if new size is not block size aligned, we zero the
+rest of block to avoid exposing stale data to user, and
+iomap_truncate_page() skips zeroing if the range is already in
+unwritten state or a hole. Then we writeback from on-disk i_size to
+the new size if this range hasn't been written to disk yet, and
+truncate page cache beyond new EOF and set in-core i_size.
+
+The problem is that we could write data between di_size and newsize
+before removing the page cache beyond newsize, as the extents may
+still be in unwritten state right after a buffer write. As such, the
+page of data that newsize lies in has not been zeroed by page cache
+invalidation before it is written, and xfs_do_writepage() hasn't
+triggered it's "zero data beyond EOF" case because we haven't
+updated in-core i_size yet. Then a subsequent mmap read could see
+non-zeros past EOF.
+
+I occasionally see this in fsx runs in fstests generic/112, a
+simplified fsx operation sequence is like (assuming 4k block size
+xfs):
+
+ fallocate 0x0 0x1000 0x0 keep_size
+ write 0x0 0x1000 0x0
+ truncate 0x0 0x800 0x1000
+ punch_hole 0x0 0x800 0x800
+ mapread 0x0 0x800 0x800
+
+where fallocate allocates unwritten extent but doesn't update
+i_size, buffer write populates the page cache and extent is still
+unwritten, truncate skips zeroing page past new EOF and writes the
+page to disk, punch_hole invalidates the page cache, at last mapread
+reads the block back and sees non-zero beyond EOF.
+
+Fix it by moving truncate_setsize() to before writeback so the page
+cache invalidation zeros the partial page at the new EOF. This also
+triggers "zero data beyond EOF" in xfs_do_writepage() at writeback
+time, because newsize has been set and page straddles the newsize.
+
+Also fixed the wrong 'end' param of filemap_write_and_wait_range()
+call while we're at it, the 'end' is inclusive and should be
+'newsize - 1'.
+
+Suggested-by: Dave Chinner <dchinner@redhat.com>
+Signed-off-by: Eryu Guan <eguan@redhat.com>
+Acked-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_iops.c | 36 ++++++++++++++++++++----------------
+ 1 file changed, 20 insertions(+), 16 deletions(-)
+
+--- a/fs/xfs/xfs_iops.c
++++ b/fs/xfs/xfs_iops.c
+@@ -886,22 +886,6 @@ xfs_setattr_size(
+ return error;
+
+ /*
+- * We are going to log the inode size change in this transaction so
+- * any previous writes that are beyond the on disk EOF and the new
+- * EOF that have not been written out need to be written here. If we
+- * do not write the data out, we expose ourselves to the null files
+- * problem. Note that this includes any block zeroing we did above;
+- * otherwise those blocks may not be zeroed after a crash.
+- */
+- if (did_zeroing ||
+- (newsize > ip->i_d.di_size && oldsize != ip->i_d.di_size)) {
+- error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping,
+- ip->i_d.di_size, newsize);
+- if (error)
+- return error;
+- }
+-
+- /*
+ * We've already locked out new page faults, so now we can safely remove
+ * pages from the page cache knowing they won't get refaulted until we
+ * drop the XFS_MMAP_EXCL lock after the extent manipulations are
+@@ -917,9 +901,29 @@ xfs_setattr_size(
+ * user visible changes). There's not much we can do about this, except
+ * to hope that the caller sees ENOMEM and retries the truncate
+ * operation.
++ *
++ * And we update in-core i_size and truncate page cache beyond newsize
++ * before writeback the [di_size, newsize] range, so we're guaranteed
++ * not to write stale data past the new EOF on truncate down.
+ */
+ truncate_setsize(inode, newsize);
+
++ /*
++ * We are going to log the inode size change in this transaction so
++ * any previous writes that are beyond the on disk EOF and the new
++ * EOF that have not been written out need to be written here. If we
++ * do not write the data out, we expose ourselves to the null files
++ * problem. Note that this includes any block zeroing we did above;
++ * otherwise those blocks may not be zeroed after a crash.
++ */
++ if (did_zeroing ||
++ (newsize > ip->i_d.di_size && oldsize != ip->i_d.di_size)) {
++ error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping,
++ ip->i_d.di_size, newsize - 1);
++ if (error)
++ return error;
++ }
++
+ error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate, 0, 0, 0, &tp);
+ if (error)
+ return error;
--- /dev/null
+From foo@baz Mon Dec 18 13:29:00 CET 2017
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Mon, 9 Oct 2017 12:03:26 -0400
+Subject: xprtrdma: Don't defer fencing an async RPC's chunks
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+
+[ Upstream commit 8f66b1a529047a972cb9602a919c53a95f3d7a2b ]
+
+In current kernels, waiting in xprt_release appears to be safe to
+do. I had erroneously believed that for ASYNC RPCs, waiting of any
+kind in xprt_release->xprt_rdma_free would result in deadlock. I've
+done injection testing and consulted with Trond to confirm that
+waiting in the RPC release path is safe.
+
+For the very few times where RPC resources haven't yet been released
+earlier by the reply handler, it is safe to wait synchronously in
+xprt_rdma_free for invalidation rather than defering it to MR
+recovery.
+
+Note: When the QP is error state, posting a LocalInvalidate should
+flush and mark the MR as bad. There is no way the remote HCA can
+access that MR via a QP in error state, so it is effectively already
+inaccessible and thus safe for the Upper Layer to access. The next
+time the MR is used it should be recognized and cleaned up properly
+by frwr_op_map.
+
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sunrpc/xprtrdma/transport.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sunrpc/xprtrdma/transport.c
++++ b/net/sunrpc/xprtrdma/transport.c
+@@ -686,7 +686,7 @@ xprt_rdma_free(struct rpc_task *task)
+ dprintk("RPC: %s: called on 0x%p\n", __func__, req->rl_reply);
+
+ if (!list_empty(&req->rl_registered))
+- ia->ri_ops->ro_unmap_safe(r_xprt, req, !RPC_IS_ASYNC(task));
++ ia->ri_ops->ro_unmap_sync(r_xprt, &req->rl_registered);
+ rpcrdma_unmap_sges(ia, req);
+ rpcrdma_buffer_put(req);
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
