--- /dev/null
+From 275ec0cb946cb75ac8977f662e608fce92f8b8a8 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 22 Jun 2018 12:17:45 +0200
+Subject: ALSA: hda/realtek - Add a quirk for FSC ESPRIMO U9210
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 275ec0cb946cb75ac8977f662e608fce92f8b8a8 upstream.
+
+Fujitsu Seimens ESPRIMO Mobile U9210 requires the same fixup as H270
+for the correct pin configs.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200107
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -2448,6 +2448,7 @@ static const struct snd_pci_quirk alc262
+ SND_PCI_QUIRK(0x10cf, 0x1397, "Fujitsu Lifebook S7110", ALC262_FIXUP_FSC_S7110),
+ SND_PCI_QUIRK(0x10cf, 0x142d, "Fujitsu Lifebook E8410", ALC262_FIXUP_BENQ),
+ SND_PCI_QUIRK(0x10f1, 0x2915, "Tyan Thunder n6650W", ALC262_FIXUP_TYAN),
++ SND_PCI_QUIRK(0x1734, 0x1141, "FSC ESPRIMO U9210", ALC262_FIXUP_FSC_H270),
+ SND_PCI_QUIRK(0x1734, 0x1147, "FSC Celsius H270", ALC262_FIXUP_FSC_H270),
+ SND_PCI_QUIRK(0x17aa, 0x384e, "Lenovo 3000", ALC262_FIXUP_LENOVO_3000),
+ SND_PCI_QUIRK(0x17ff, 0x0560, "Benq ED8", ALC262_FIXUP_BENQ),
--- /dev/null
+From d5a6cabf02210b896a60eee7c04c670ee9ba6dca Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 13 Jun 2018 12:43:10 +0200
+Subject: ALSA: hda/realtek - Fix pop noise on Lenovo P50 & co
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit d5a6cabf02210b896a60eee7c04c670ee9ba6dca upstream.
+
+Some Lenovo laptops, e.g. Lenovo P50, showed the pop noise at resume
+or runtime resume. It turned out to be reduced by applying
+alc_no_shutup() just like TPT440 quirk does.
+
+Since there are many Lenovo models showing the same behavior, put this
+workaround in ALC269_FIXUP_THINKPAD_ACPI entry so that it's applied
+commonly to all such Lenovo machines.
+
+Reported-by: Hans de Goede <hdegoede@redhat.com>
+Tested-by: Benjamin Berg <bberg@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -4473,7 +4473,6 @@ static void alc_fixup_tpt440_dock(struct
+ struct alc_spec *spec = codec->spec;
+
+ if (action == HDA_FIXUP_ACT_PRE_PROBE) {
+- spec->shutup = alc_no_shutup; /* reduce click noise */
+ spec->reboot_notify = alc_d3_at_reboot; /* reduce noise */
+ spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP;
+ codec->power_save_node = 0; /* avoid click noises */
+@@ -4835,6 +4834,13 @@ static void alc280_fixup_hp_9480m(struct
+ /* for hda_fixup_thinkpad_acpi() */
+ #include "thinkpad_helper.c"
+
++static void alc_fixup_thinkpad_acpi(struct hda_codec *codec,
++ const struct hda_fixup *fix, int action)
++{
++ alc_fixup_no_shutup(codec, fix, action); /* reduce click noise */
++ hda_fixup_thinkpad_acpi(codec, fix, action);
++}
++
+ /* for dell wmi mic mute led */
+ #include "dell_wmi_helper.c"
+
+@@ -5350,7 +5356,7 @@ static const struct hda_fixup alc269_fix
+ },
+ [ALC269_FIXUP_THINKPAD_ACPI] = {
+ .type = HDA_FIXUP_FUNC,
+- .v.func = hda_fixup_thinkpad_acpi,
++ .v.func = alc_fixup_thinkpad_acpi,
+ .chained = true,
+ .chain_id = ALC269_FIXUP_SKU_IGNORE,
+ },
--- /dev/null
+From 4a9c8bb2aca5b5a2a15744333729745dd9903562 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 20 Nov 2017 11:45:44 +0100
+Subject: backlight: as3711_bl: Fix Device Tree node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 4a9c8bb2aca5b5a2a15744333729745dd9903562 upstream.
+
+Fix child-node lookup during probe, which ended up searching the whole
+device tree depth-first starting at the parent rather than just matching
+on its children.
+
+To make things worse, the parent mfd node was also prematurely freed.
+
+Cc: stable <stable@vger.kernel.org> # 3.10
+Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/backlight/as3711_bl.c | 33 +++++++++++++++++++++++----------
+ 1 file changed, 23 insertions(+), 10 deletions(-)
+
+--- a/drivers/video/backlight/as3711_bl.c
++++ b/drivers/video/backlight/as3711_bl.c
+@@ -262,10 +262,10 @@ static int as3711_bl_register(struct pla
+ static int as3711_backlight_parse_dt(struct device *dev)
+ {
+ struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
+- struct device_node *bl =
+- of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
++ struct device_node *bl, *fb;
+ int ret;
+
++ bl = of_get_child_by_name(dev->parent->of_node, "backlight");
+ if (!bl) {
+ dev_dbg(dev, "backlight node not found\n");
+ return -ENODEV;
+@@ -279,7 +279,7 @@ static int as3711_backlight_parse_dt(str
+ if (pdata->su1_max_uA <= 0)
+ ret = -EINVAL;
+ if (ret < 0)
+- return ret;
++ goto err_put_bl;
+ }
+
+ fb = of_parse_phandle(bl, "su2-dev", 0);
+@@ -292,7 +292,7 @@ static int as3711_backlight_parse_dt(str
+ if (pdata->su2_max_uA <= 0)
+ ret = -EINVAL;
+ if (ret < 0)
+- return ret;
++ goto err_put_bl;
+
+ if (of_find_property(bl, "su2-feedback-voltage", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_VOLTAGE;
+@@ -314,8 +314,10 @@ static int as3711_backlight_parse_dt(str
+ pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
+ count++;
+ }
+- if (count != 1)
+- return -EINVAL;
++ if (count != 1) {
++ ret = -EINVAL;
++ goto err_put_bl;
++ }
+
+ count = 0;
+ if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
+@@ -334,8 +336,10 @@ static int as3711_backlight_parse_dt(str
+ pdata->su2_fbprot = AS3711_SU2_GPIO4;
+ count++;
+ }
+- if (count != 1)
+- return -EINVAL;
++ if (count != 1) {
++ ret = -EINVAL;
++ goto err_put_bl;
++ }
+
+ count = 0;
+ if (of_find_property(bl, "su2-auto-curr1", NULL)) {
+@@ -355,11 +359,20 @@ static int as3711_backlight_parse_dt(str
+ * At least one su2-auto-curr* must be specified iff
+ * AS3711_SU2_CURR_AUTO is used
+ */
+- if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
+- return -EINVAL;
++ if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) {
++ ret = -EINVAL;
++ goto err_put_bl;
++ }
+ }
+
++ of_node_put(bl);
++
+ return 0;
++
++err_put_bl:
++ of_node_put(bl);
++
++ return ret;
+ }
+
+ static int as3711_backlight_probe(struct platform_device *pdev)
--- /dev/null
+From d1cc0ec3da23e44c23712579515494b374f111c9 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 20 Nov 2017 11:45:45 +0100
+Subject: backlight: max8925_bl: Fix Device Tree node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit d1cc0ec3da23e44c23712579515494b374f111c9 upstream.
+
+Fix child-node lookup during probe, which ended up searching the whole
+device tree depth-first starting at the parent rather than just matching
+on its children.
+
+To make things worse, the parent mfd node was also prematurely freed,
+while the child backlight node was leaked.
+
+Cc: stable <stable@vger.kernel.org> # 3.9
+Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/backlight/max8925_bl.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/backlight/max8925_bl.c
++++ b/drivers/video/backlight/max8925_bl.c
+@@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(st
+ if (!pdata)
+ return;
+
+- np = of_find_node_by_name(nproot, "backlight");
++ np = of_get_child_by_name(nproot, "backlight");
+ if (!np) {
+ dev_err(&pdev->dev, "failed to find backlight node\n");
+ return;
+@@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(st
+ if (!of_property_read_u32(np, "maxim,max8925-dual-string", &val))
+ pdata->dual_string = val;
+
++ of_node_put(np);
++
+ pdev->dev.platform_data = pdata;
+ }
+
--- /dev/null
+From 2b12dfa124dbadf391cb9a616aaa6b056823bf75 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 20 Nov 2017 11:45:46 +0100
+Subject: backlight: tps65217_bl: Fix Device Tree node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 2b12dfa124dbadf391cb9a616aaa6b056823bf75 upstream.
+
+Fix child-node lookup during probe, which ended up searching the whole
+device tree depth-first starting at the parent rather than just matching
+on its children.
+
+This would only cause trouble if the child node is missing while there
+is an unrelated node named "backlight" elsewhere in the tree.
+
+Cc: stable <stable@vger.kernel.org> # 3.7
+Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/backlight/tps65217_bl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/video/backlight/tps65217_bl.c
++++ b/drivers/video/backlight/tps65217_bl.c
+@@ -184,11 +184,11 @@ static struct tps65217_bl_pdata *
+ tps65217_bl_parse_dt(struct platform_device *pdev)
+ {
+ struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
+- struct device_node *node = of_node_get(tps->dev->of_node);
++ struct device_node *node;
+ struct tps65217_bl_pdata *pdata, *err;
+ u32 val;
+
+- node = of_find_node_by_name(node, "backlight");
++ node = of_get_child_by_name(tps->dev->of_node, "backlight");
+ if (!node)
+ return ERR_PTR(-ENODEV);
+
--- /dev/null
+From a982e45dc150da3a08907b6dd676b735391704b4 Mon Sep 17 00:00:00 2001
+From: Marcin Ziemianowicz <marcin@ziemianowicz.com>
+Date: Sun, 29 Apr 2018 15:01:11 -0400
+Subject: clk: at91: PLL recalc_rate() now using cached MUL and DIV values
+
+From: Marcin Ziemianowicz <marcin@ziemianowicz.com>
+
+commit a982e45dc150da3a08907b6dd676b735391704b4 upstream.
+
+When a USB device is connected to the USB host port on the SAM9N12 then
+you get "-62" error which seems to indicate USB replies from the device
+are timing out. Based on a logic sniffer, I saw the USB bus was running
+at half speed.
+
+The PLL code uses cached MUL and DIV values which get set in set_rate()
+and applied in prepare(), but the recalc_rate() function instead
+queries the hardware instead of using these cached values. Therefore,
+if recalc_rate() is called between a set_rate() and prepare(), the
+wrong frequency is calculated and later the USB clock divider for the
+SAM9N12 SOC will be configured for an incorrect clock.
+
+In my case, the PLL hardware was set to 96 Mhz before the OHCI
+driver loads, and therefore the usb clock divider was being set
+to /2 even though the OHCI driver set the PLL to 48 Mhz.
+
+As an alternative explanation, I noticed this was fixed in the past by
+87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
+driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
+at91: make use of syscon/regmap internally").
+
+Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Marcin Ziemianowicz <marcin@ziemianowicz.com>
+Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/at91/clk-pll.c | 13 +------------
+ 1 file changed, 1 insertion(+), 12 deletions(-)
+
+--- a/drivers/clk/at91/clk-pll.c
++++ b/drivers/clk/at91/clk-pll.c
+@@ -132,19 +132,8 @@ static unsigned long clk_pll_recalc_rate
+ unsigned long parent_rate)
+ {
+ struct clk_pll *pll = to_clk_pll(hw);
+- unsigned int pllr;
+- u16 mul;
+- u8 div;
+
+- regmap_read(pll->regmap, PLL_REG(pll->id), &pllr);
+-
+- div = PLL_DIV(pllr);
+- mul = PLL_MUL(pllr, pll->layout);
+-
+- if (!div || !mul)
+- return 0;
+-
+- return (parent_rate / div) * (mul + 1);
++ return (parent_rate / pll->div) * (pll->mul + 1);
+ }
+
+ static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
--- /dev/null
+From 8938fc7b8fe9ccfa11751ead502a8d385b607967 Mon Sep 17 00:00:00 2001
+From: Alexandr Savca <alexandr.savca@saltedge.com>
+Date: Thu, 21 Jun 2018 17:12:54 -0700
+Subject: Input: elan_i2c - add ELAN0618 (Lenovo v330 15IKB) ACPI ID
+
+From: Alexandr Savca <alexandr.savca@saltedge.com>
+
+commit 8938fc7b8fe9ccfa11751ead502a8d385b607967 upstream.
+
+Add ELAN0618 to the list of supported touchpads; this ID is used in
+Lenovo v330 15IKB devices.
+
+Signed-off-by: Alexandr Savca <alexandr.savca@saltedge.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1250,6 +1250,7 @@ static const struct acpi_device_id elan_
+ { "ELAN060C", 0 },
+ { "ELAN0611", 0 },
+ { "ELAN0612", 0 },
++ { "ELAN0618", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From 50fc7b61959af4b95fafce7fe5dd565199e0b61a Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Date: Tue, 19 Jun 2018 11:17:32 -0700
+Subject: Input: elan_i2c_smbus - fix more potential stack buffer overflows
+
+From: Ben Hutchings <ben.hutchings@codethink.co.uk>
+
+commit 50fc7b61959af4b95fafce7fe5dd565199e0b61a upstream.
+
+Commit 40f7090bb1b4 ("Input: elan_i2c_smbus - fix corrupted stack")
+fixed most of the functions using i2c_smbus_read_block_data() to
+allocate a buffer with the maximum block size. However three
+functions were left unchanged:
+
+* In elan_smbus_initialize(), increase the buffer size in the same
+ way.
+* In elan_smbus_calibrate_result(), the buffer is provided by the
+ caller (calibrate_store()), so introduce a bounce buffer. Also
+ name the result buffer size.
+* In elan_smbus_get_report(), the buffer is provided by the caller
+ but happens to be the right length. Add a compile-time assertion
+ to ensure this remains the case.
+
+Cc: <stable@vger.kernel.org> # 3.19+
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c.h | 2 ++
+ drivers/input/mouse/elan_i2c_core.c | 2 +-
+ drivers/input/mouse/elan_i2c_smbus.c | 10 ++++++++--
+ 3 files changed, 11 insertions(+), 3 deletions(-)
+
+--- a/drivers/input/mouse/elan_i2c.h
++++ b/drivers/input/mouse/elan_i2c.h
+@@ -27,6 +27,8 @@
+ #define ETP_DISABLE_POWER 0x0001
+ #define ETP_PRESSURE_OFFSET 25
+
++#define ETP_CALIBRATE_MAX_LEN 3
++
+ /* IAP Firmware handling */
+ #define ETP_PRODUCT_ID_FORMAT_STRING "%d.0"
+ #define ETP_FW_NAME "elan_i2c_" ETP_PRODUCT_ID_FORMAT_STRING ".bin"
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -595,7 +595,7 @@ static ssize_t calibrate_store(struct de
+ int tries = 20;
+ int retval;
+ int error;
+- u8 val[3];
++ u8 val[ETP_CALIBRATE_MAX_LEN];
+
+ retval = mutex_lock_interruptible(&data->sysfs_mutex);
+ if (retval)
+--- a/drivers/input/mouse/elan_i2c_smbus.c
++++ b/drivers/input/mouse/elan_i2c_smbus.c
+@@ -56,7 +56,7 @@
+ static int elan_smbus_initialize(struct i2c_client *client)
+ {
+ u8 check[ETP_SMBUS_HELLOPACKET_LEN] = { 0x55, 0x55, 0x55, 0x55, 0x55 };
+- u8 values[ETP_SMBUS_HELLOPACKET_LEN] = { 0, 0, 0, 0, 0 };
++ u8 values[I2C_SMBUS_BLOCK_MAX] = {0};
+ int len, error;
+
+ /* Get hello packet */
+@@ -117,12 +117,16 @@ static int elan_smbus_calibrate(struct i
+ static int elan_smbus_calibrate_result(struct i2c_client *client, u8 *val)
+ {
+ int error;
++ u8 buf[I2C_SMBUS_BLOCK_MAX] = {0};
++
++ BUILD_BUG_ON(ETP_CALIBRATE_MAX_LEN > sizeof(buf));
+
+ error = i2c_smbus_read_block_data(client,
+- ETP_SMBUS_CALIBRATE_QUERY, val);
++ ETP_SMBUS_CALIBRATE_QUERY, buf);
+ if (error < 0)
+ return error;
+
++ memcpy(val, buf, ETP_CALIBRATE_MAX_LEN);
+ return 0;
+ }
+
+@@ -470,6 +474,8 @@ static int elan_smbus_get_report(struct
+ {
+ int len;
+
++ BUILD_BUG_ON(I2C_SMBUS_BLOCK_MAX > ETP_SMBUS_REPORT_LEN);
++
+ len = i2c_smbus_read_block_data(client,
+ ETP_SMBUS_PACKET_QUERY,
+ &report[ETP_SMBUS_REPORT_OFFSET]);
--- /dev/null
+From 24bb555e6e46d96e2a954aa0295029a81cc9bbaa Mon Sep 17 00:00:00 2001
+From: Aaron Ma <aaron.ma@canonical.com>
+Date: Thu, 21 Jun 2018 17:14:01 -0700
+Subject: Input: elantech - enable middle button of touchpads on ThinkPad P52
+
+From: Aaron Ma <aaron.ma@canonical.com>
+
+commit 24bb555e6e46d96e2a954aa0295029a81cc9bbaa upstream.
+
+PNPID is better way to identify the type of touchpads.
+Enable middle button support on 2 types of touchpads on Lenovo P52.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elantech.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -1173,6 +1173,12 @@ static const struct dmi_system_id elante
+ { }
+ };
+
++static const char * const middle_button_pnp_ids[] = {
++ "LEN2131", /* ThinkPad P52 w/ NFC */
++ "LEN2132", /* ThinkPad P52 */
++ NULL
++};
++
+ /*
+ * Set the appropriate event bits for the input subsystem
+ */
+@@ -1192,7 +1198,8 @@ static int elantech_set_input_params(str
+ __clear_bit(EV_REL, dev->evbit);
+
+ __set_bit(BTN_LEFT, dev->keybit);
+- if (dmi_check_system(elantech_dmi_has_middle_button))
++ if (dmi_check_system(elantech_dmi_has_middle_button) ||
++ psmouse_matches_pnp_id(psmouse, middle_button_pnp_ids))
+ __set_bit(BTN_MIDDLE, dev->keybit);
+ __set_bit(BTN_RIGHT, dev->keybit);
+
--- /dev/null
+From e0ae2519ca004a628fa55aeef969c37edce522d3 Mon Sep 17 00:00:00 2001
+From: ??? <kt.liao@emc.com.tw>
+Date: Thu, 21 Jun 2018 17:15:32 -0700
+Subject: Input: elantech - fix V4 report decoding for module with middle key
+
+From: ??? <kt.liao@emc.com.tw>
+
+commit e0ae2519ca004a628fa55aeef969c37edce522d3 upstream.
+
+Some touchpad has middle key and it will be indicated in bit 2 of packet[0].
+We need to fix V4 formation's byte mask to prevent error decoding.
+
+Signed-off-by: KT Liao <kt.liao@emc.com.tw>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elantech.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -800,7 +800,7 @@ static int elantech_packet_check_v4(stru
+ else if (ic_version == 7 && etd->samples[1] == 0x2A)
+ sanity_check = ((packet[3] & 0x1c) == 0x10);
+ else
+- sanity_check = ((packet[0] & 0x0c) == 0x04 &&
++ sanity_check = ((packet[0] & 0x08) == 0x00 &&
+ (packet[3] & 0x1c) == 0x10);
+
+ if (!sanity_check)
--- /dev/null
+From 254a4cd50b9fe2291a12b8902e08e56dcc4e9b10 Mon Sep 17 00:00:00 2001
+From: Robert Elliott <elliott@hpe.com>
+Date: Thu, 31 May 2018 18:36:36 -0500
+Subject: linvdimm, pmem: Preserve read-only setting for pmem devices
+
+From: Robert Elliott <elliott@hpe.com>
+
+commit 254a4cd50b9fe2291a12b8902e08e56dcc4e9b10 upstream.
+
+The pmem driver does not honor a forced read-only setting for very long:
+ $ blockdev --setro /dev/pmem0
+ $ blockdev --getro /dev/pmem0
+ 1
+
+followed by various commands like these:
+ $ blockdev --rereadpt /dev/pmem0
+ or
+ $ mkfs.ext4 /dev/pmem0
+
+results in this in the kernel serial log:
+ nd_pmem namespace0.0: region0 read-write, marking pmem0 read-write
+
+with the read-only setting lost:
+ $ blockdev --getro /dev/pmem0
+ 0
+
+That's from bus.c nvdimm_revalidate_disk(), which always applies the
+setting from nd_region (which is initially based on the ACPI NFIT
+NVDIMM state flags not_armed bit).
+
+In contrast, commit 20bd1d026aac ("scsi: sd: Keep disk read-only when
+re-reading partition") fixed this issue for SCSI devices to preserve
+the previous setting if it was set to read-only.
+
+This patch modifies bus.c to preserve any previous read-only setting.
+It also eliminates the kernel serial log print except for cases where
+read-write is changed to read-only, so it doesn't print read-only to
+read-only non-changes.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 581388209405 ("libnvdimm, nfit: handle unarmed dimms, mark namespaces read-only")
+Signed-off-by: Robert Elliott <elliott@hpe.com>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/nvdimm/bus.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/nvdimm/bus.c
++++ b/drivers/nvdimm/bus.c
+@@ -505,14 +505,18 @@ int nvdimm_revalidate_disk(struct gendis
+ {
+ struct device *dev = disk_to_dev(disk)->parent;
+ struct nd_region *nd_region = to_nd_region(dev->parent);
+- const char *pol = nd_region->ro ? "only" : "write";
++ int disk_ro = get_disk_ro(disk);
+
+- if (nd_region->ro == get_disk_ro(disk))
++ /*
++ * Upgrade to read-only if the region is read-only preserve as
++ * read-only if the disk is already read-only.
++ */
++ if (disk_ro || nd_region->ro == disk_ro)
+ return 0;
+
+- dev_info(dev, "%s read-%s, marking %s read-%s\n",
+- dev_name(&nd_region->dev), pol, disk->disk_name, pol);
+- set_disk_ro(disk, nd_region->ro);
++ dev_info(dev, "%s read-only, marking %s read-only\n",
++ dev_name(&nd_region->dev), disk->disk_name);
++ set_disk_ro(disk, 1);
+
+ return 0;
+
--- /dev/null
+From 011abdc9df559ec75779bb7c53a744c69b2a94c6 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Thu, 26 Apr 2018 14:46:29 +1000
+Subject: md: fix two problems with setting the "re-add" device state.
+
+From: NeilBrown <neilb@suse.com>
+
+commit 011abdc9df559ec75779bb7c53a744c69b2a94c6 upstream.
+
+If "re-add" is written to the "state" file for a device
+which is faulty, this has an effect similar to removing
+and re-adding the device. It should take up the
+same slot in the array that it previously had, and
+an accelerated (e.g. bitmap-based) rebuild should happen.
+
+The slot that "it previously had" is determined by
+rdev->saved_raid_disk.
+However this is not set when a device fails (only when a device
+is added), and it is cleared when resync completes.
+This means that "re-add" will normally work once, but may not work a
+second time.
+
+This patch includes two fixes.
+1/ when a device fails, record the ->raid_disk value in
+ ->saved_raid_disk before clearing ->raid_disk
+2/ when "re-add" is written to a device for which
+ ->saved_raid_disk is not set, fail.
+
+I think this is suitable for stable as it can
+cause re-adding a device to be forced to do a full
+resync which takes a lot longer and so puts data at
+more risk.
+
+Cc: <stable@vger.kernel.org> (v4.1)
+Fixes: 97f6cd39da22 ("md-cluster: re-add capabilities")
+Signed-off-by: NeilBrown <neilb@suse.com>
+Reviewed-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -2694,7 +2694,8 @@ state_store(struct md_rdev *rdev, const
+ err = 0;
+ }
+ } else if (cmd_match(buf, "re-add")) {
+- if (test_bit(Faulty, &rdev->flags) && (rdev->raid_disk == -1)) {
++ if (test_bit(Faulty, &rdev->flags) && (rdev->raid_disk == -1) &&
++ rdev->saved_raid_disk >= 0) {
+ /* clear_bit is performed _after_ all the devices
+ * have their local Faulty bit cleared. If any writes
+ * happen in the meantime in the local node, they
+@@ -8272,6 +8273,7 @@ static int remove_and_add_spares(struct
+ if (mddev->pers->hot_remove_disk(
+ mddev, rdev) == 0) {
+ sysfs_unlink_rdev(mddev, rdev);
++ rdev->saved_raid_disk = rdev->raid_disk;
+ rdev->raid_disk = -1;
+ removed++;
+ }
--- /dev/null
+From 29e61d6ef061b012d320327af7dbb3990e75be45 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Mon, 26 Mar 2018 02:06:16 -0400
+Subject: media: cx231xx: Add support for AverMedia DVD EZMaker 7
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 29e61d6ef061b012d320327af7dbb3990e75be45 upstream.
+
+User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER.
+Add the device to the id_table to make it work.
+
+BugLink: https://bugs.launchpad.net/bugs/1620762
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Hans Verkuil <hansverk@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/cx231xx/cx231xx-cards.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
++++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
+@@ -864,6 +864,9 @@ struct usb_device_id cx231xx_id_table[]
+ .driver_info = CX231XX_BOARD_CNXT_RDE_250},
+ {USB_DEVICE(0x0572, 0x58A0),
+ .driver_info = CX231XX_BOARD_CNXT_RDU_250},
++ /* AverMedia DVD EZMaker 7 */
++ {USB_DEVICE(0x07ca, 0xc039),
++ .driver_info = CX231XX_BOARD_CNXT_VIDEO_GRABBER},
+ {USB_DEVICE(0x2040, 0xb110),
+ .driver_info = CX231XX_BOARD_HAUPPAUGE_USB2_FM_PAL},
+ {USB_DEVICE(0x2040, 0xb111),
--- /dev/null
+From 76d81243a487c09619822ef8e7201a756e58a87d Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Date: Thu, 5 Apr 2018 05:30:52 -0400
+Subject: media: dvb_frontend: fix locking issues at dvb_frontend_get_event()
+
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+
+commit 76d81243a487c09619822ef8e7201a756e58a87d upstream.
+
+As warned by smatch:
+ drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'.
+ Locked on: line 288
+ line 295
+ line 306
+ line 314
+ Unlocked on: line 303
+
+The lock implementation for get event is wrong, as, if an
+interrupt occurs, down_interruptible() will fail, and the
+routine will call up() twice when userspace calls the ioctl
+again.
+
+The bad code is there since when Linux migrated to git, in
+2005.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/dvb-core/dvb_frontend.c | 23 +++++++++++++++--------
+ 1 file changed, 15 insertions(+), 8 deletions(-)
+
+--- a/drivers/media/dvb-core/dvb_frontend.c
++++ b/drivers/media/dvb-core/dvb_frontend.c
+@@ -251,8 +251,20 @@ static void dvb_frontend_add_event(struc
+ wake_up_interruptible (&events->wait_queue);
+ }
+
++static int dvb_frontend_test_event(struct dvb_frontend_private *fepriv,
++ struct dvb_fe_events *events)
++{
++ int ret;
++
++ up(&fepriv->sem);
++ ret = events->eventw != events->eventr;
++ down(&fepriv->sem);
++
++ return ret;
++}
++
+ static int dvb_frontend_get_event(struct dvb_frontend *fe,
+- struct dvb_frontend_event *event, int flags)
++ struct dvb_frontend_event *event, int flags)
+ {
+ struct dvb_frontend_private *fepriv = fe->frontend_priv;
+ struct dvb_fe_events *events = &fepriv->events;
+@@ -270,13 +282,8 @@ static int dvb_frontend_get_event(struct
+ if (flags & O_NONBLOCK)
+ return -EWOULDBLOCK;
+
+- up(&fepriv->sem);
+-
+- ret = wait_event_interruptible (events->wait_queue,
+- events->eventw != events->eventr);
+-
+- if (down_interruptible (&fepriv->sem))
+- return -ERESTARTSYS;
++ ret = wait_event_interruptible(events->wait_queue,
++ dvb_frontend_test_event(fepriv, events));
+
+ if (ret < 0)
+ return ret;
--- /dev/null
+From ea72fbf588ac9c017224dcdaa2019ff52ca56fee Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Date: Wed, 11 Apr 2018 11:47:32 -0400
+Subject: media: v4l2-compat-ioctl32: prevent go past max size
+
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+
+commit ea72fbf588ac9c017224dcdaa2019ff52ca56fee upstream.
+
+As warned by smatch:
+ drivers/media/v4l2-core/v4l2-compat-ioctl32.c:879 put_v4l2_ext_controls32() warn: check for integer overflow 'count'
+
+The access_ok() logic should check for too big arrays too.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
++++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+@@ -864,7 +864,7 @@ static int put_v4l2_ext_controls32(struc
+ get_user(kcontrols, &kp->controls))
+ return -EFAULT;
+
+- if (!count)
++ if (!count || count > (U32_MAX/sizeof(*ucontrols)))
+ return 0;
+ if (get_user(p, &up->controls))
+ return -EFAULT;
--- /dev/null
+From d28b62520830b2d0bffa2d98e81afc9f5e537e8b Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 24 Apr 2018 18:00:10 +0300
+Subject: mfd: intel-lpss: Program REMAP register in PIO mode
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit d28b62520830b2d0bffa2d98e81afc9f5e537e8b upstream.
+
+According to documentation REMAP register has to be programmed in
+either DMA or PIO mode of the slice.
+
+Move the DMA capability check below to let REMAP register be programmed
+in PIO mode.
+
+Cc: stable@vger.kernel.org # 4.3+
+Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mfd/intel-lpss.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mfd/intel-lpss.c
++++ b/drivers/mfd/intel-lpss.c
+@@ -275,11 +275,11 @@ static void intel_lpss_init_dev(const st
+
+ intel_lpss_deassert_reset(lpss);
+
++ intel_lpss_set_remap_addr(lpss);
++
+ if (!intel_lpss_has_idma(lpss))
+ return;
+
+- intel_lpss_set_remap_addr(lpss);
+-
+ /* Make sure that SPI multiblock DMA transfers are re-enabled */
+ if (lpss->type == LPSS_DEV_SPI)
+ writel(value, lpss->priv + LPSS_PRIV_SSP_REG);
--- /dev/null
+From 2bdce74412c249ac01dfe36b6b0043ffd7a5361e Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Thu, 14 Jun 2018 15:26:24 -0700
+Subject: mm: fix devmem_is_allowed() for sub-page System RAM intersections
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 2bdce74412c249ac01dfe36b6b0043ffd7a5361e upstream.
+
+Hussam reports:
+
+ I was poking around and for no real reason, I did cat /dev/mem and
+ strings /dev/mem. Then I saw the following warning in dmesg. I saved it
+ and rebooted immediately.
+
+ memremap attempted on mixed range 0x000000000009c000 size: 0x1000
+ ------------[ cut here ]------------
+ WARNING: CPU: 0 PID: 11810 at kernel/memremap.c:98 memremap+0x104/0x170
+ [..]
+ Call Trace:
+ xlate_dev_mem_ptr+0x25/0x40
+ read_mem+0x89/0x1a0
+ __vfs_read+0x36/0x170
+
+The memremap() implementation checks for attempts to remap System RAM
+with MEMREMAP_WB and instead redirects those mapping attempts to the
+linear map. However, that only works if the physical address range
+being remapped is page aligned. In low memory we have situations like
+the following:
+
+ 00000000-00000fff : Reserved
+ 00001000-0009fbff : System RAM
+ 0009fc00-0009ffff : Reserved
+
+...where System RAM intersects Reserved ranges on a sub-page page
+granularity.
+
+Given that devmem_is_allowed() special cases any attempt to map System
+RAM in the first 1MB of memory, replace page_is_ram() with the more
+precise region_intersects() to trap attempts to map disallowed ranges.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=199999
+Link: http://lkml.kernel.org/r/152856436164.18127.2847888121707136898.stgit@dwillia2-desk3.amr.corp.intel.com
+Fixes: 92281dee825f ("arch: introduce memremap()")
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Reported-by: Hussam Al-Tayeb <me@hussam.eu.org>
+Tested-by: Hussam Al-Tayeb <me@hussam.eu.org>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/init.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/mm/init.c
++++ b/arch/x86/mm/init.c
+@@ -653,7 +653,9 @@ void __init init_mem_mapping(void)
+ */
+ int devmem_is_allowed(unsigned long pagenr)
+ {
+- if (page_is_ram(pagenr)) {
++ if (region_intersects(PFN_PHYS(pagenr), PAGE_SIZE,
++ IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE)
++ != REGION_DISJOINT) {
+ /*
+ * For disallowed memory regions in the low 1MB range,
+ * request that the page be shown as all zeros.
--- /dev/null
+From 9c2ece6ef67e9d376f32823086169b489c422ed0 Mon Sep 17 00:00:00 2001
+From: Scott Mayhew <smayhew@redhat.com>
+Date: Mon, 7 May 2018 09:01:08 -0400
+Subject: nfsd: restrict rd_maxcount to svc_max_payload in nfsd_encode_readdir
+
+From: Scott Mayhew <smayhew@redhat.com>
+
+commit 9c2ece6ef67e9d376f32823086169b489c422ed0 upstream.
+
+nfsd4_readdir_rsize restricts rd_maxcount to svc_max_payload when
+estimating the size of the readdir reply, but nfsd_encode_readdir
+restricts it to INT_MAX when encoding the reply. This can result in log
+messages like "kernel: RPC request reserved 32896 but used 1049444".
+
+Restrict rd_dircount similarly (no reason it should be larger than
+svc_max_payload).
+
+Signed-off-by: Scott Mayhew <smayhew@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/nfs4xdr.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/fs/nfsd/nfs4xdr.c
++++ b/fs/nfsd/nfs4xdr.c
+@@ -3638,7 +3638,8 @@ nfsd4_encode_readdir(struct nfsd4_compou
+ nfserr = nfserr_resource;
+ goto err_no_verf;
+ }
+- maxcount = min_t(u32, readdir->rd_maxcount, INT_MAX);
++ maxcount = svc_max_payload(resp->rqstp);
++ maxcount = min_t(u32, readdir->rd_maxcount, maxcount);
+ /*
+ * Note the rfc defines rd_maxcount as the size of the
+ * READDIR4resok structure, which includes the verifier above
+@@ -3652,7 +3653,7 @@ nfsd4_encode_readdir(struct nfsd4_compou
+
+ /* RFC 3530 14.2.24 allows us to ignore dircount when it's 0: */
+ if (!readdir->rd_dircount)
+- readdir->rd_dircount = INT_MAX;
++ readdir->rd_dircount = svc_max_payload(resp->rqstp);
+
+ readdir->xdr = xdr;
+ readdir->rd_maxcount = maxcount;
--- /dev/null
+From d68894800ec5712d7ddf042356f11e36f87d7f78 Mon Sep 17 00:00:00 2001
+From: Dave Wysochanski <dwysocha@redhat.com>
+Date: Tue, 29 May 2018 17:47:30 -0400
+Subject: NFSv4: Fix possible 1-byte stack overflow in nfs_idmap_read_and_verify_message
+
+From: Dave Wysochanski <dwysocha@redhat.com>
+
+commit d68894800ec5712d7ddf042356f11e36f87d7f78 upstream.
+
+In nfs_idmap_read_and_verify_message there is an incorrect sprintf '%d'
+that converts the __u32 'im_id' from struct idmap_msg to 'id_str', which
+is a stack char array variable of length NFS_UINT_MAXLEN == 11.
+If a uid or gid value is > 2147483647 = 0x7fffffff, the conversion
+overflows into a negative value, for example:
+crash> p (unsigned) (0x80000000)
+$1 = 2147483648
+crash> p (signed) (0x80000000)
+$2 = -2147483648
+The '-' sign is written to the buffer and this causes a 1 byte overflow
+when the NULL byte is written, which corrupts kernel stack memory. If
+CONFIG_CC_STACKPROTECTOR_STRONG is set we see a stack-protector panic:
+
+[11558053.616565] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa05b8a8c
+[11558053.639063] CPU: 6 PID: 9423 Comm: rpc.idmapd Tainted: G W ------------ T 3.10.0-514.el7.x86_64 #1
+[11558053.641990] Hardware name: Red Hat OpenStack Compute, BIOS 1.10.2-3.el7_4.1 04/01/2014
+[11558053.644462] ffffffff818c7bc0 00000000b1f3aec1 ffff880de0f9bd48 ffffffff81685eac
+[11558053.646430] ffff880de0f9bdc8 ffffffff8167f2b3 ffffffff00000010 ffff880de0f9bdd8
+[11558053.648313] ffff880de0f9bd78 00000000b1f3aec1 ffffffff811dcb03 ffffffffa05b8a8c
+[11558053.650107] Call Trace:
+[11558053.651347] [<ffffffff81685eac>] dump_stack+0x19/0x1b
+[11558053.653013] [<ffffffff8167f2b3>] panic+0xe3/0x1f2
+[11558053.666240] [<ffffffff811dcb03>] ? kfree+0x103/0x140
+[11558053.682589] [<ffffffffa05b8a8c>] ? idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4]
+[11558053.689710] [<ffffffff810855db>] __stack_chk_fail+0x1b/0x30
+[11558053.691619] [<ffffffffa05b8a8c>] idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4]
+[11558053.693867] [<ffffffffa00209d6>] rpc_pipe_write+0x56/0x70 [sunrpc]
+[11558053.695763] [<ffffffff811fe12d>] vfs_write+0xbd/0x1e0
+[11558053.702236] [<ffffffff810acccc>] ? task_work_run+0xac/0xe0
+[11558053.704215] [<ffffffff811fec4f>] SyS_write+0x7f/0xe0
+[11558053.709674] [<ffffffff816964c9>] system_call_fastpath+0x16/0x1b
+
+Fix this by calling the internally defined nfs_map_numeric_to_string()
+function which properly uses '%u' to convert this __u32. For consistency,
+also replace the one other place where snprintf is called.
+
+Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
+Reported-by: Stephen Johnston <sjohnsto@redhat.com>
+Fixes: cf4ab538f1516 ("NFSv4: Fix the string length returned by the idmapper")
+Cc: stable@vger.kernel.org # v3.4+
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4idmap.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/fs/nfs/nfs4idmap.c
++++ b/fs/nfs/nfs4idmap.c
+@@ -343,7 +343,7 @@ static ssize_t nfs_idmap_lookup_name(__u
+ int id_len;
+ ssize_t ret;
+
+- id_len = snprintf(id_str, sizeof(id_str), "%u", id);
++ id_len = nfs_map_numeric_to_string(id, id_str, sizeof(id_str));
+ ret = nfs_idmap_get_key(id_str, id_len, type, buf, buflen, idmap);
+ if (ret < 0)
+ return -EINVAL;
+@@ -626,7 +626,8 @@ static int nfs_idmap_read_and_verify_mes
+ if (strcmp(upcall->im_name, im->im_name) != 0)
+ break;
+ /* Note: here we store the NUL terminator too */
+- len = sprintf(id_str, "%d", im->im_id) + 1;
++ len = 1 + nfs_map_numeric_to_string(im->im_id, id_str,
++ sizeof(id_str));
+ ret = nfs_idmap_instantiate(key, authkey, id_str, len);
+ break;
+ case IDMAP_CONV_IDTONAME:
--- /dev/null
+From fc40724fc6731d90cc7fb6d62d66135f85a33dd2 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+Date: Sat, 9 Jun 2018 12:43:06 -0400
+Subject: NFSv4: Revert commit 5f83d86cf531d ("NFSv4.x: Fix wraparound issues..")
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+commit fc40724fc6731d90cc7fb6d62d66135f85a33dd2 upstream.
+
+The correct behaviour for NFSv4 sequence IDs is to wrap around
+to the value 0 after 0xffffffff.
+See https://tools.ietf.org/html/rfc5661#section-2.10.6.1
+
+Fixes: 5f83d86cf531d ("NFSv4.x: Fix wraparound issues when validing...")
+Cc: stable@vger.kernel.org # 4.6+
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/callback_proc.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/fs/nfs/callback_proc.c
++++ b/fs/nfs/callback_proc.c
+@@ -402,11 +402,8 @@ validate_seqid(const struct nfs4_slot_ta
+ return htonl(NFS4ERR_SEQ_FALSE_RETRY);
+ }
+
+- /* Wraparound */
+- if (unlikely(slot->seq_nr == 0xFFFFFFFFU)) {
+- if (args->csa_sequenceid == 1)
+- return htonl(NFS4_OK);
+- } else if (likely(args->csa_sequenceid == slot->seq_nr + 1))
++ /* Note: wraparound relies on seq_nr being of type u32 */
++ if (likely(args->csa_sequenceid == slot->seq_nr + 1))
+ return htonl(NFS4_OK);
+
+ /* Misordered request */
--- /dev/null
+From bd2e49ec48feb1855f7624198849eea4610e2286 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Thu, 31 May 2018 13:23:43 +0300
+Subject: perf intel-pt: Fix decoding to accept CBR between FUP and corresponding TIP
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit bd2e49ec48feb1855f7624198849eea4610e2286 upstream.
+
+It is possible to have a CBR packet between a FUP packet and
+corresponding TIP packet. Stop treating it as an error.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1527762225-26024-3-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -1517,7 +1517,6 @@ static int intel_pt_walk_fup_tip(struct
+ case INTEL_PT_PSB:
+ case INTEL_PT_TSC:
+ case INTEL_PT_TMA:
+- case INTEL_PT_CBR:
+ case INTEL_PT_MODE_TSX:
+ case INTEL_PT_BAD:
+ case INTEL_PT_PSBEND:
+@@ -1526,6 +1525,10 @@ static int intel_pt_walk_fup_tip(struct
+ decoder->pkt_step = 0;
+ return -ENOENT;
+
++ case INTEL_PT_CBR:
++ intel_pt_calc_cbr(decoder);
++ break;
++
+ case INTEL_PT_OVF:
+ return intel_pt_overflow(decoder);
+
--- /dev/null
+From dd27b87ab5fcf3ea1c060b5e3ab5d31cc78e9f4c Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Thu, 31 May 2018 13:23:44 +0300
+Subject: perf intel-pt: Fix MTC timing after overflow
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit dd27b87ab5fcf3ea1c060b5e3ab5d31cc78e9f4c upstream.
+
+On some platforms, overflows will clear before MTC wraparound, and there
+is no following TSC/TMA packet. In that case the previous TMA is valid.
+Since there will be a valid TMA either way, stop setting 'have_tma' to
+false upon overflow.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1527762225-26024-4-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -1298,7 +1298,6 @@ static int intel_pt_overflow(struct inte
+ {
+ intel_pt_log("ERROR: Buffer overflow\n");
+ intel_pt_clear_tx_flags(decoder);
+- decoder->have_tma = false;
+ decoder->cbr = 0;
+ decoder->timestamp_insn_cnt = 0;
+ decoder->pkt_state = INTEL_PT_STATE_ERR_RESYNC;
--- /dev/null
+From 621a5a327c1e36ffd7bb567f44a559f64f76358f Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Thu, 7 Jun 2018 14:30:02 +0300
+Subject: perf intel-pt: Fix packet decoding of CYC packets
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 621a5a327c1e36ffd7bb567f44a559f64f76358f upstream.
+
+Use a 64-bit type so that the cycle count is not limited to 32-bits.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1528371002-8862-1-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
+@@ -281,7 +281,7 @@ static int intel_pt_get_cyc(unsigned int
+ if (len < offs)
+ return INTEL_PT_NEED_MORE_BYTES;
+ byte = buf[offs++];
+- payload |= (byte >> 1) << shift;
++ payload |= ((uint64_t)byte >> 1) << shift;
+ }
+
+ packet->type = INTEL_PT_CYC;
--- /dev/null
+From dbcb82b93f3e8322891e47472c89e63058b81e99 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Thu, 31 May 2018 13:23:42 +0300
+Subject: perf intel-pt: Fix sync_switch INTEL_PT_SS_NOT_TRACING
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit dbcb82b93f3e8322891e47472c89e63058b81e99 upstream.
+
+sync_switch is a facility to synchronize decoding more closely with the
+point in the kernel when the context actually switched.
+
+In one case, INTEL_PT_SS_NOT_TRACING state was not correctly
+transitioning to INTEL_PT_SS_TRACING state due to a missing case clause.
+Add it.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1527762225-26024-2-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tools/perf/util/intel-pt.c
++++ b/tools/perf/util/intel-pt.c
+@@ -1344,6 +1344,7 @@ static int intel_pt_sample(struct intel_
+
+ if (intel_pt_is_switch_ip(ptq, state->to_ip)) {
+ switch (ptq->switch_state) {
++ case INTEL_PT_SS_NOT_TRACING:
+ case INTEL_PT_SS_UNKNOWN:
+ case INTEL_PT_SS_EXPECTING_SWITCH_IP:
+ err = intel_pt_next_tid(pt, ptq);
--- /dev/null
+From 9fb523363f6e3984457fee95bb7019395384ffa7 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Thu, 31 May 2018 13:23:45 +0300
+Subject: perf intel-pt: Fix "Unexpected indirect branch" error
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 9fb523363f6e3984457fee95bb7019395384ffa7 upstream.
+
+Some Atom CPUs can produce FUP packets that contain NLIP (next linear
+instruction pointer) instead of CLIP (current linear instruction
+pointer). That will result in "Unexpected indirect branch" errors. Fix
+by comparing IP to NLIP in that case.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1527762225-26024-5-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 17 +++++++++++++++--
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.h | 9 +++++++++
+ tools/perf/util/intel-pt.c | 4 ++++
+ 3 files changed, 28 insertions(+), 2 deletions(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -112,6 +112,7 @@ struct intel_pt_decoder {
+ bool have_cyc;
+ bool fixup_last_mtc;
+ bool have_last_ip;
++ enum intel_pt_param_flags flags;
+ uint64_t pos;
+ uint64_t last_ip;
+ uint64_t ip;
+@@ -215,6 +216,8 @@ struct intel_pt_decoder *intel_pt_decode
+ decoder->data = params->data;
+ decoder->return_compression = params->return_compression;
+
++ decoder->flags = params->flags;
++
+ decoder->period = params->period;
+ decoder->period_type = params->period_type;
+
+@@ -1012,6 +1015,15 @@ out_no_progress:
+ return err;
+ }
+
++static inline bool intel_pt_fup_with_nlip(struct intel_pt_decoder *decoder,
++ struct intel_pt_insn *intel_pt_insn,
++ uint64_t ip, int err)
++{
++ return decoder->flags & INTEL_PT_FUP_WITH_NLIP && !err &&
++ intel_pt_insn->branch == INTEL_PT_BR_INDIRECT &&
++ ip == decoder->ip + intel_pt_insn->length;
++}
++
+ static int intel_pt_walk_fup(struct intel_pt_decoder *decoder)
+ {
+ struct intel_pt_insn intel_pt_insn;
+@@ -1024,7 +1036,8 @@ static int intel_pt_walk_fup(struct inte
+ err = intel_pt_walk_insn(decoder, &intel_pt_insn, ip);
+ if (err == INTEL_PT_RETURN)
+ return 0;
+- if (err == -EAGAIN) {
++ if (err == -EAGAIN ||
++ intel_pt_fup_with_nlip(decoder, &intel_pt_insn, ip, err)) {
+ if (decoder->set_fup_tx_flags) {
+ decoder->set_fup_tx_flags = false;
+ decoder->tx_flags = decoder->fup_tx_flags;
+@@ -1034,7 +1047,7 @@ static int intel_pt_walk_fup(struct inte
+ decoder->state.flags = decoder->fup_tx_flags;
+ return 0;
+ }
+- return err;
++ return -EAGAIN;
+ }
+ decoder->set_fup_tx_flags = false;
+ if (err)
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
+@@ -53,6 +53,14 @@ enum {
+ INTEL_PT_ERR_MAX,
+ };
+
++enum intel_pt_param_flags {
++ /*
++ * FUP packet can contain next linear instruction pointer instead of
++ * current linear instruction pointer.
++ */
++ INTEL_PT_FUP_WITH_NLIP = 1 << 0,
++};
++
+ struct intel_pt_state {
+ enum intel_pt_sample_type type;
+ int err;
+@@ -92,6 +100,7 @@ struct intel_pt_params {
+ unsigned int mtc_period;
+ uint32_t tsc_ctc_ratio_n;
+ uint32_t tsc_ctc_ratio_d;
++ enum intel_pt_param_flags flags;
+ };
+
+ struct intel_pt_decoder;
+--- a/tools/perf/util/intel-pt.c
++++ b/tools/perf/util/intel-pt.c
+@@ -752,6 +752,7 @@ static struct intel_pt_queue *intel_pt_a
+ unsigned int queue_nr)
+ {
+ struct intel_pt_params params = { .get_trace = 0, };
++ struct perf_env *env = pt->machine->env;
+ struct intel_pt_queue *ptq;
+
+ ptq = zalloc(sizeof(struct intel_pt_queue));
+@@ -832,6 +833,9 @@ static struct intel_pt_queue *intel_pt_a
+ }
+ }
+
++ if (env->cpuid && !strncmp(env->cpuid, "GenuineIntel,6,92,", 18))
++ params.flags |= INTEL_PT_FUP_WITH_NLIP;
++
+ ptq->decoder = intel_pt_decoder_new(¶ms);
+ if (!ptq->decoder)
+ goto out_free;
--- /dev/null
+From aef4feace285f27c8ed35830a5d575bec7f3e90a Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 4 Jun 2018 15:56:54 +0300
+Subject: perf tools: Fix symbol and object code resolution for vdso32 and vdsox32
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit aef4feace285f27c8ed35830a5d575bec7f3e90a upstream.
+
+Fix __kmod_path__parse() so that perf tools does not treat vdso32 and
+vdsox32 as kernel modules and fail to find the object.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Wang Nan <wangnan0@huawei.com>
+Cc: stable@vger.kernel.org
+Fixes: 1f121b03d058 ("perf tools: Deal with kernel module names in '[]' correctly")
+Link: http://lkml.kernel.org/r/1528117014-30032-3-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/dso.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/tools/perf/util/dso.c
++++ b/tools/perf/util/dso.c
+@@ -253,6 +253,8 @@ int __kmod_path__parse(struct kmod_path
+ if ((strncmp(name, "[kernel.kallsyms]", 17) == 0) ||
+ (strncmp(name, "[guest.kernel.kallsyms", 22) == 0) ||
+ (strncmp(name, "[vdso]", 6) == 0) ||
++ (strncmp(name, "[vdso32]", 8) == 0) ||
++ (strncmp(name, "[vdsox32]", 9) == 0) ||
+ (strncmp(name, "[vsyscall]", 10) == 0)) {
+ m->kmod = false;
+
--- /dev/null
+From 1d375b58c12f08d8570b30b865def4734517f04f Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Thu, 26 Apr 2018 14:10:23 +0200
+Subject: pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 1d375b58c12f08d8570b30b865def4734517f04f upstream.
+
+On some devices the contents of the ctrl register get lost over a
+suspend/resume and the PWM comes back up disabled after the resume.
+
+This is seen on some Bay Trail devices with the PWM in ACPI enumerated
+mode, so it shows up as a platform device instead of a PCI device.
+
+If we still think it is enabled and then try to change the duty-cycle
+after this, we end up with a "PWM_SW_UPDATE was not cleared" error and
+the PWM is stuck in that state from then on.
+
+This commit adds suspend and resume pm callbacks to the pwm-lpss-platform
+code, which save/restore the ctrl register over a suspend/resume, fixing
+this.
+
+Note that:
+
+1) There is no need to do this over a runtime suspend, since we
+only runtime suspend when disabled and then we properly set the enable
+bit and reprogram the timings when we re-enable the PWM.
+
+2) This may be happening on more systems then we realize, but has been
+covered up sofar by a bug in the acpi-lpss.c code which was save/restoring
+the regular device registers instead of the lpss private registers due to
+lpss_device_desc.prv_offset not being set. This is fixed by a later patch
+in this series.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pwm/pwm-lpss-platform.c | 5 +++++
+ drivers/pwm/pwm-lpss.c | 30 ++++++++++++++++++++++++++++++
+ drivers/pwm/pwm-lpss.h | 2 ++
+ 3 files changed, 37 insertions(+)
+
+--- a/drivers/pwm/pwm-lpss-platform.c
++++ b/drivers/pwm/pwm-lpss-platform.c
+@@ -52,6 +52,10 @@ static int pwm_lpss_remove_platform(stru
+ return pwm_lpss_remove(lpwm);
+ }
+
++static SIMPLE_DEV_PM_OPS(pwm_lpss_platform_pm_ops,
++ pwm_lpss_suspend,
++ pwm_lpss_resume);
++
+ static const struct acpi_device_id pwm_lpss_acpi_match[] = {
+ { "80860F09", (unsigned long)&pwm_lpss_byt_info },
+ { "80862288", (unsigned long)&pwm_lpss_bsw_info },
+@@ -64,6 +68,7 @@ static struct platform_driver pwm_lpss_d
+ .driver = {
+ .name = "pwm-lpss",
+ .acpi_match_table = pwm_lpss_acpi_match,
++ .pm = &pwm_lpss_platform_pm_ops,
+ },
+ .probe = pwm_lpss_probe_platform,
+ .remove = pwm_lpss_remove_platform,
+--- a/drivers/pwm/pwm-lpss.c
++++ b/drivers/pwm/pwm-lpss.c
+@@ -31,10 +31,13 @@
+ /* Size of each PWM register space if multiple */
+ #define PWM_SIZE 0x400
+
++#define MAX_PWMS 4
++
+ struct pwm_lpss_chip {
+ struct pwm_chip chip;
+ void __iomem *regs;
+ const struct pwm_lpss_boardinfo *info;
++ u32 saved_ctrl[MAX_PWMS];
+ };
+
+ /* BayTrail */
+@@ -168,6 +171,9 @@ struct pwm_lpss_chip *pwm_lpss_probe(str
+ unsigned long c;
+ int ret;
+
++ if (WARN_ON(info->npwm > MAX_PWMS))
++ return ERR_PTR(-ENODEV);
++
+ lpwm = devm_kzalloc(dev, sizeof(*lpwm), GFP_KERNEL);
+ if (!lpwm)
+ return ERR_PTR(-ENOMEM);
+@@ -203,6 +209,30 @@ int pwm_lpss_remove(struct pwm_lpss_chip
+ }
+ EXPORT_SYMBOL_GPL(pwm_lpss_remove);
+
++int pwm_lpss_suspend(struct device *dev)
++{
++ struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
++ int i;
++
++ for (i = 0; i < lpwm->info->npwm; i++)
++ lpwm->saved_ctrl[i] = readl(lpwm->regs + i * PWM_SIZE + PWM);
++
++ return 0;
++}
++EXPORT_SYMBOL_GPL(pwm_lpss_suspend);
++
++int pwm_lpss_resume(struct device *dev)
++{
++ struct pwm_lpss_chip *lpwm = dev_get_drvdata(dev);
++ int i;
++
++ for (i = 0; i < lpwm->info->npwm; i++)
++ writel(lpwm->saved_ctrl[i], lpwm->regs + i * PWM_SIZE + PWM);
++
++ return 0;
++}
++EXPORT_SYMBOL_GPL(pwm_lpss_resume);
++
+ MODULE_DESCRIPTION("PWM driver for Intel LPSS");
+ MODULE_AUTHOR("Mika Westerberg <mika.westerberg@linux.intel.com>");
+ MODULE_LICENSE("GPL v2");
+--- a/drivers/pwm/pwm-lpss.h
++++ b/drivers/pwm/pwm-lpss.h
+@@ -31,5 +31,7 @@ extern const struct pwm_lpss_boardinfo p
+ struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
+ const struct pwm_lpss_boardinfo *info);
+ int pwm_lpss_remove(struct pwm_lpss_chip *lpwm);
++int pwm_lpss_suspend(struct device *dev);
++int pwm_lpss_resume(struct device *dev);
+
+ #endif /* __PWM_LPSS_H */
--- /dev/null
+From 23edca864951250af845a11da86bb3ea63522ed2 Mon Sep 17 00:00:00 2001
+From: Dongsheng Yang <dongsheng.yang@easystack.cn>
+Date: Mon, 4 Jun 2018 06:24:37 -0400
+Subject: rbd: flush rbd_dev->watch_dwork after watch is unregistered
+
+From: Dongsheng Yang <dongsheng.yang@easystack.cn>
+
+commit 23edca864951250af845a11da86bb3ea63522ed2 upstream.
+
+There is a problem if we are going to unmap a rbd device and the
+watch_dwork is going to queue delayed work for watch:
+
+unmap Thread watch Thread timer
+do_rbd_remove
+ cancel_tasks_sync(rbd_dev)
+ queue_delayed_work for watch
+ destroy_workqueue(rbd_dev->task_wq)
+ drain_workqueue(wq)
+ destroy other resources in wq
+ call_timer_fn
+ __queue_work()
+
+Then the delayed work escape the cancel_tasks_sync() and
+destroy_workqueue() and we will get an user-after-free call trace:
+
+ BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
+ PGD 0 P4D 0
+ Oops: 0000 [#1] SMP PTI
+ Modules linked in:
+ CPU: 7 PID: 0 Comm: swapper/7 Tainted: G OE 4.17.0-rc6+ #13
+ Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
+ RIP: 0010:__queue_work+0x6a/0x3b0
+ RSP: 0018:ffff9427df1c3e90 EFLAGS: 00010086
+ RAX: ffff9427deca8400 RBX: 0000000000000000 RCX: 0000000000000000
+ RDX: ffff9427deca8400 RSI: ffff9427df1c3e50 RDI: 0000000000000000
+ RBP: ffff942783e39e00 R08: ffff9427deca8400 R09: ffff9427df1c3f00
+ R10: 0000000000000004 R11: 0000000000000005 R12: ffff9427cfb85970
+ R13: 0000000000002000 R14: 000000000001eca0 R15: 0000000000000007
+ FS: 0000000000000000(0000) GS:ffff9427df1c0000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000000 CR3: 00000004c900a005 CR4: 00000000000206e0
+ Call Trace:
+ <IRQ>
+ ? __queue_work+0x3b0/0x3b0
+ call_timer_fn+0x2d/0x130
+ run_timer_softirq+0x16e/0x430
+ ? tick_sched_timer+0x37/0x70
+ __do_softirq+0xd2/0x280
+ irq_exit+0xd5/0xe0
+ smp_apic_timer_interrupt+0x6c/0x130
+ apic_timer_interrupt+0xf/0x20
+
+[ Move rbd_dev->watch_dwork cancellation so that rbd_reregister_watch()
+ either bails out early because the watch is UNREGISTERED at that point
+ or just gets cancelled. ]
+
+Cc: stable@vger.kernel.org
+Fixes: 99d1694310df ("rbd: retry watch re-registration periodically")
+Signed-off-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/rbd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -3900,7 +3900,6 @@ static void cancel_tasks_sync(struct rbd
+ {
+ dout("%s rbd_dev %p\n", __func__, rbd_dev);
+
+- cancel_delayed_work_sync(&rbd_dev->watch_dwork);
+ cancel_work_sync(&rbd_dev->acquired_lock_work);
+ cancel_work_sync(&rbd_dev->released_lock_work);
+ cancel_delayed_work_sync(&rbd_dev->lock_dwork);
+@@ -3918,6 +3917,7 @@ static void rbd_unregister_watch(struct
+ rbd_dev->watch_state = RBD_WATCH_STATE_UNREGISTERED;
+ mutex_unlock(&rbd_dev->watch_mutex);
+
++ cancel_delayed_work_sync(&rbd_dev->watch_dwork);
+ ceph_osdc_flush_notifies(&rbd_dev->rbd_client->client->osdc);
+ }
+
--- /dev/null
+From 4a2e84c6ed85434ce7843e4844b4d3263f7e233b Mon Sep 17 00:00:00 2001
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Date: Mon, 4 Jun 2018 10:39:01 +0100
+Subject: rpmsg: smd: do not use mananged resources for endpoints and channels
+
+From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+commit 4a2e84c6ed85434ce7843e4844b4d3263f7e233b upstream.
+
+All the managed resources would be freed by the time release function
+is invoked. Handling such memory in qcom_smd_edge_release() would do
+bad things.
+
+Found this issue while testing Audio usecase where the dsp is started up
+and shutdown in a loop.
+
+This patch fixes this issue by using simple kzalloc for allocating
+channel->name and channel which is then freed in qcom_smd_edge_release().
+
+Without this patch restarting a remoteproc would crash the system.
+Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/rpmsg/qcom_smd.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/drivers/rpmsg/qcom_smd.c
++++ b/drivers/rpmsg/qcom_smd.c
+@@ -1006,12 +1006,12 @@ static struct qcom_smd_channel *qcom_smd
+ void *info;
+ int ret;
+
+- channel = devm_kzalloc(&edge->dev, sizeof(*channel), GFP_KERNEL);
++ channel = kzalloc(sizeof(*channel), GFP_KERNEL);
+ if (!channel)
+ return ERR_PTR(-ENOMEM);
+
+ channel->edge = edge;
+- channel->name = devm_kstrdup(&edge->dev, name, GFP_KERNEL);
++ channel->name = kstrdup(name, GFP_KERNEL);
+ if (!channel->name)
+ return ERR_PTR(-ENOMEM);
+
+@@ -1061,8 +1061,8 @@ static struct qcom_smd_channel *qcom_smd
+ return channel;
+
+ free_name_and_channel:
+- devm_kfree(&edge->dev, channel->name);
+- devm_kfree(&edge->dev, channel);
++ kfree(channel->name);
++ kfree(channel);
+
+ return ERR_PTR(ret);
+ }
+@@ -1279,13 +1279,13 @@ static int qcom_smd_parse_edge(struct de
+ */
+ static void qcom_smd_edge_release(struct device *dev)
+ {
+- struct qcom_smd_channel *channel;
++ struct qcom_smd_channel *channel, *tmp;
+ struct qcom_smd_edge *edge = to_smd_edge(dev);
+
+- list_for_each_entry(channel, &edge->channels, list) {
+- SET_RX_CHANNEL_INFO(channel, state, SMD_CHANNEL_CLOSED);
+- SET_RX_CHANNEL_INFO(channel, head, 0);
+- SET_RX_CHANNEL_INFO(channel, tail, 0);
++ list_for_each_entry_safe(channel, tmp, &edge->channels, list) {
++ list_del(&channel->list);
++ kfree(channel->name);
++ kfree(channel);
+ }
+
+ kfree(edge);
--- /dev/null
+From 413c2f33489b134e3cc65d9c3ff7861e8fdfe899 Mon Sep 17 00:00:00 2001
+From: Himanshu Madhani <himanshu.madhani@cavium.com>
+Date: Sun, 3 Jun 2018 22:09:53 -0700
+Subject: scsi: qla2xxx: Fix setting lower transfer speed if GPSC fails
+
+From: Himanshu Madhani <himanshu.madhani@cavium.com>
+
+commit 413c2f33489b134e3cc65d9c3ff7861e8fdfe899 upstream.
+
+This patch prevents driver from setting lower default speed of 1 GB/sec,
+if the switch does not support Get Port Speed Capabilities (GPSC)
+command. Setting this default speed results into much lower write
+performance for large sequential WRITE. This patch modifies driver to
+check for gpsc_supported flags and prevents driver from issuing
+MBC_SET_PORT_PARAM (001Ah) to set default speed of 1 GB/sec. If driver
+does not send this mailbox command, firmware assumes maximum supported
+link speed and will operate at the max speed.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
+Reported-by: Eda Zhou <ezhou@redhat.com>
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Tested-by: Ewan D. Milne <emilne@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_init.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/qla2xxx/qla_init.c
++++ b/drivers/scsi/qla2xxx/qla_init.c
+@@ -3319,7 +3319,8 @@ qla2x00_iidma_fcport(scsi_qla_host_t *vh
+ return;
+
+ if (fcport->fp_speed == PORT_SPEED_UNKNOWN ||
+- fcport->fp_speed > ha->link_data_rate)
++ fcport->fp_speed > ha->link_data_rate ||
++ !ha->flags.gpsc_supported)
+ return;
+
+ rval = qla2x00_set_idma_speed(vha, fcport->loop_id, fcport->fp_speed,
--- /dev/null
+From 3cedc8797b9c0f2222fd45a01f849c57c088828b Mon Sep 17 00:00:00 2001
+From: Anil Gurumurthy <anil.gurumurthy@cavium.com>
+Date: Wed, 6 Jun 2018 08:41:42 -0700
+Subject: scsi: qla2xxx: Mask off Scope bits in retry delay
+
+From: Anil Gurumurthy <anil.gurumurthy@cavium.com>
+
+commit 3cedc8797b9c0f2222fd45a01f849c57c088828b upstream.
+
+Some newer target uses "Status Qualifier" response in a returned "Busy
+Status". This new response code of 0x4001, which is "Scope" bits,
+translates to "Affects all units accessible by target". Due to this new
+value returned in the Scope bits, driver was using that value as timeout
+value which resulted into driver waiting for 27min timeout.
+
+This patch masks off this Scope bits so that driver does not use this
+value as retry delay time.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Anil Gurumurthy <anil.gurumurthy@cavium.com>
+Signed-off-by: Giridhar Malavali <giridhar.malavali@cavium.com>
+Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Reviewed-by: Martin Wilck <mwilck@suse.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_isr.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_isr.c
++++ b/drivers/scsi/qla2xxx/qla_isr.c
+@@ -2168,8 +2168,12 @@ qla2x00_status_entry(scsi_qla_host_t *vh
+ ox_id = le16_to_cpu(sts24->ox_id);
+ par_sense_len = sizeof(sts24->data);
+ /* Valid values of the retry delay timer are 0x1-0xffef */
+- if (sts24->retry_delay > 0 && sts24->retry_delay < 0xfff1)
+- retry_delay = sts24->retry_delay;
++ if (sts24->retry_delay > 0 && sts24->retry_delay < 0xfff1) {
++ retry_delay = sts24->retry_delay & 0x3fff;
++ ql_dbg(ql_dbg_io, sp->vha, 0x3033,
++ "%s: scope=%#x retry_delay=%#x\n", __func__,
++ sts24->retry_delay >> 14, retry_delay);
++ }
+ } else {
+ if (scsi_status & SS_SENSE_LEN_VALID)
+ sense_len = le16_to_cpu(sts->req_sense_length);
--- /dev/null
+From 512857a795cbbda5980efa4cdb3c0b6602330408 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:45 +0200
+Subject: scsi: zfcp: fix misleading REC trigger trace where erp_action setup failed
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit 512857a795cbbda5980efa4cdb3c0b6602330408 upstream.
+
+If a SCSI device is deleted during scsi_eh host reset, we cannot get a
+reference to the SCSI device anymore since scsi_device_get returns !=0 by
+design. Assuming the recovery of adapter and port(s) was successful,
+zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for the
+half-gone SCSI device. Unfortunately, it causes the following confusing
+trace record which states that zfcp will do a LUN recovery as "ERP need" is
+ZFCP_ERP_ACTION_REOPEN_LUN == 1 and equals "ERP want".
+
+Old example trace record formatted with zfcpdbf from s390-tools:
+
+Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded
+LUN : 0x<FCP_LUN>
+WWPN : 0x<WWPN>
+D_ID : 0x<N_Port-ID>
+Adapter status : 0x5400050b
+Port status : 0x54000001
+LUN status : 0x40000000 ZFCP_STATUS_COMMON_RUNNING
+ but not ZFCP_STATUS_COMMON_UNBLOCKED as it
+ was closed on close part of adapter reopen
+ERP want : 0x01
+ERP need : 0x01 misleading
+
+However, zfcp_erp_setup_act() returns NULL as it cannot get the reference.
+Hence, zfcp_erp_action_enqueue() takes an early goto out and _NO_ recovery
+actually happens.
+
+We always do want the recovery trigger trace record even if no erp_action
+could be enqueued as in this case. For other cases where we did not enqueue
+an erp_action, 'need' has always been zero to indicate this. In order to
+indicate above goto out, introduce an eyecatcher "flag" to mark the "ERP
+need" as 'not needed' but still keep the information which erp_action type,
+that zfcp_erp_required_act() had decided upon, is needed. 0xc_ is chosen to
+be visibly different from 0x0_ in "ERP want".
+
+New example trace record formatted with zfcpdbf from s390-tools:
+
+Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded
+LUN : 0x<FCP_LUN>
+WWPN : 0x<WWPN>
+D_ID : 0x<N_Port-ID>
+Adapter status : 0x5400050b
+Port status : 0x54000001
+LUN status : 0x40000000
+ERP want : 0x01
+ERP need : 0xc1 would need LUN ERP, but no action set up
+ ^
+
+Before v2.6.38 commit ae0904f60fab ("[SCSI] zfcp: Redesign of the debug
+tracing for recovery actions.") we could detect this case because the
+"erp_action" field in the trace was NULL. The rework removed erp_action as
+argument and field from the trace.
+
+This patch here is for tracing. A fix to allow LUN recovery in the case at
+hand is a topic for a separate patch.
+
+See also commit fdbd1c5e27da ("[SCSI] zfcp: Allow running unit/LUN shutdown
+without acquiring reference") for a similar case and background info.
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_erp.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -34,11 +34,23 @@ enum zfcp_erp_steps {
+ ZFCP_ERP_STEP_LUN_OPENING = 0x2000,
+ };
+
++/**
++ * enum zfcp_erp_act_type - Type of ERP action object.
++ * @ZFCP_ERP_ACTION_REOPEN_LUN: LUN recovery.
++ * @ZFCP_ERP_ACTION_REOPEN_PORT: Port recovery.
++ * @ZFCP_ERP_ACTION_REOPEN_PORT_FORCED: Forced port recovery.
++ * @ZFCP_ERP_ACTION_REOPEN_ADAPTER: Adapter recovery.
++ * @ZFCP_ERP_ACTION_NONE: Eyecatcher pseudo flag to bitwise or-combine with
++ * either of the other enum values.
++ * Used to indicate that an ERP action could not be
++ * set up despite a detected need for some recovery.
++ */
+ enum zfcp_erp_act_type {
+ ZFCP_ERP_ACTION_REOPEN_LUN = 1,
+ ZFCP_ERP_ACTION_REOPEN_PORT = 2,
+ ZFCP_ERP_ACTION_REOPEN_PORT_FORCED = 3,
+ ZFCP_ERP_ACTION_REOPEN_ADAPTER = 4,
++ ZFCP_ERP_ACTION_NONE = 0xc0,
+ };
+
+ enum zfcp_erp_act_state {
+@@ -256,8 +268,10 @@ static int zfcp_erp_action_enqueue(int w
+ goto out;
+
+ act = zfcp_erp_setup_act(need, act_status, adapter, port, sdev);
+- if (!act)
++ if (!act) {
++ need |= ZFCP_ERP_ACTION_NONE; /* marker for trace */
+ goto out;
++ }
+ atomic_or(ZFCP_STATUS_ADAPTER_ERP_PENDING, &adapter->status);
+ ++adapter->erp_total_count;
+ list_add_tail(&act->list, &adapter->erp_ready_head);
--- /dev/null
+From 8c3d20aada70042a39c6a6625be037c1472ca610 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:48 +0200
+Subject: scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit 8c3d20aada70042a39c6a6625be037c1472ca610 upstream.
+
+That other commit introduced an inconsistency because it would trace on
+ERP_FAILED for all callers of port forced reopen triggers (not just
+terminate_rport_io), but it would not trace on ERP_FAILED for all callers of
+other ERP triggers such as adapter, port regular, LUN.
+
+Therefore, generalize that other commit. zfcp_erp_action_enqueue() already
+had two early outs which re-used the one zfcp_dbf_rec_trig() call. All ERP
+trigger functions finally run through zfcp_erp_action_enqueue(). So move
+the special handling for ZFCP_STATUS_COMMON_ERP_FAILED into
+zfcp_erp_action_enqueue() and add another early out with new trace marker
+for pseudo ERP need in this case. This removes all early returns from all
+ERP trigger functions so we always end up at zfcp_dbf_rec_trig().
+
+Example trace record formatted with zfcpdbf from s390-tools:
+
+Timestamp : ...
+Area : REC
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1 ZFCP_DBF_REC_TRIG
+Tag : .......
+LUN : 0x...
+WWPN : 0x...
+D_ID : 0x...
+Adapter status : 0x...
+Port status : 0x...
+LUN status : 0x...
+Ready count : 0x...
+Running count : 0x...
+ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_...
+ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_erp.c | 79 +++++++++++++++++++++++++++----------------
+ 1 file changed, 51 insertions(+), 28 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -142,6 +142,49 @@ static void zfcp_erp_action_dismiss_adap
+ }
+ }
+
++static int zfcp_erp_handle_failed(int want, struct zfcp_adapter *adapter,
++ struct zfcp_port *port,
++ struct scsi_device *sdev)
++{
++ int need = want;
++ struct zfcp_scsi_dev *zsdev;
++
++ switch (want) {
++ case ZFCP_ERP_ACTION_REOPEN_LUN:
++ zsdev = sdev_to_zfcp(sdev);
++ if (atomic_read(&zsdev->status) & ZFCP_STATUS_COMMON_ERP_FAILED)
++ need = 0;
++ break;
++ case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
++ if (atomic_read(&port->status) & ZFCP_STATUS_COMMON_ERP_FAILED)
++ need = 0;
++ break;
++ case ZFCP_ERP_ACTION_REOPEN_PORT:
++ if (atomic_read(&port->status) &
++ ZFCP_STATUS_COMMON_ERP_FAILED) {
++ need = 0;
++ /* ensure propagation of failed status to new devices */
++ zfcp_erp_set_port_status(
++ port, ZFCP_STATUS_COMMON_ERP_FAILED);
++ }
++ break;
++ case ZFCP_ERP_ACTION_REOPEN_ADAPTER:
++ if (atomic_read(&adapter->status) &
++ ZFCP_STATUS_COMMON_ERP_FAILED) {
++ need = 0;
++ /* ensure propagation of failed status to new devices */
++ zfcp_erp_set_adapter_status(
++ adapter, ZFCP_STATUS_COMMON_ERP_FAILED);
++ }
++ break;
++ default:
++ need = 0;
++ break;
++ }
++
++ return need;
++}
++
+ static int zfcp_erp_required_act(int want, struct zfcp_adapter *adapter,
+ struct zfcp_port *port,
+ struct scsi_device *sdev)
+@@ -265,6 +308,12 @@ static int zfcp_erp_action_enqueue(int w
+ int retval = 1, need;
+ struct zfcp_erp_action *act;
+
++ need = zfcp_erp_handle_failed(want, adapter, port, sdev);
++ if (!need) {
++ need = ZFCP_ERP_ACTION_FAILED; /* marker for trace */
++ goto out;
++ }
++
+ if (!adapter->erp_thread)
+ return -EIO;
+
+@@ -313,12 +362,6 @@ static int _zfcp_erp_adapter_reopen(stru
+ zfcp_erp_adapter_block(adapter, clear_mask);
+ zfcp_scsi_schedule_rports_block(adapter);
+
+- /* ensure propagation of failed status to new devices */
+- if (atomic_read(&adapter->status) & ZFCP_STATUS_COMMON_ERP_FAILED) {
+- zfcp_erp_set_adapter_status(adapter,
+- ZFCP_STATUS_COMMON_ERP_FAILED);
+- return -EIO;
+- }
+ return zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_ADAPTER,
+ adapter, NULL, NULL, id, 0);
+ }
+@@ -337,12 +380,8 @@ void zfcp_erp_adapter_reopen(struct zfcp
+ zfcp_scsi_schedule_rports_block(adapter);
+
+ write_lock_irqsave(&adapter->erp_lock, flags);
+- if (atomic_read(&adapter->status) & ZFCP_STATUS_COMMON_ERP_FAILED)
+- zfcp_erp_set_adapter_status(adapter,
+- ZFCP_STATUS_COMMON_ERP_FAILED);
+- else
+- zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_ADAPTER, adapter,
+- NULL, NULL, id, 0);
++ zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_ADAPTER, adapter,
++ NULL, NULL, id, 0);
+ write_unlock_irqrestore(&adapter->erp_lock, flags);
+ }
+
+@@ -383,13 +422,6 @@ static void _zfcp_erp_port_forced_reopen
+ zfcp_erp_port_block(port, clear);
+ zfcp_scsi_schedule_rport_block(port);
+
+- if (atomic_read(&port->status) & ZFCP_STATUS_COMMON_ERP_FAILED) {
+- zfcp_dbf_rec_trig(id, port->adapter, port, NULL,
+- ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
+- ZFCP_ERP_ACTION_FAILED);
+- return;
+- }
+-
+ zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
+ port->adapter, port, NULL, id, 0);
+ }
+@@ -415,12 +447,6 @@ static int _zfcp_erp_port_reopen(struct
+ zfcp_erp_port_block(port, clear);
+ zfcp_scsi_schedule_rport_block(port);
+
+- if (atomic_read(&port->status) & ZFCP_STATUS_COMMON_ERP_FAILED) {
+- /* ensure propagation of failed status to new devices */
+- zfcp_erp_set_port_status(port, ZFCP_STATUS_COMMON_ERP_FAILED);
+- return -EIO;
+- }
+-
+ return zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_PORT,
+ port->adapter, port, NULL, id, 0);
+ }
+@@ -460,9 +486,6 @@ static void _zfcp_erp_lun_reopen(struct
+
+ zfcp_erp_lun_block(sdev, clear);
+
+- if (atomic_read(&zfcp_sdev->status) & ZFCP_STATUS_COMMON_ERP_FAILED)
+- return;
+-
+ zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_LUN, adapter,
+ zfcp_sdev->port, sdev, id, act_status);
+ }
--- /dev/null
+From 6a76550841d412330bd86aed3238d1888ba70f0e Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:49 +0200
+Subject: scsi: zfcp: fix missing REC trigger trace on enqueue without ERP thread
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit 6a76550841d412330bd86aed3238d1888ba70f0e upstream.
+
+Example trace record formatted with zfcpdbf from s390-tools:
+
+Timestamp : ...
+Area : REC
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1 ZFCP_DBF_REC_TRIG
+Tag : .......
+LUN : 0x...
+WWPN : 0x...
+D_ID : 0x...
+Adapter status : 0x...
+Port status : 0x...
+LUN status : 0x...
+Ready count : 0x...
+Running count : 0x...
+ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_...
+ERP need : 0xc0 ZFCP_ERP_ACTION_NONE
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_erp.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -314,8 +314,11 @@ static int zfcp_erp_action_enqueue(int w
+ goto out;
+ }
+
+- if (!adapter->erp_thread)
+- return -EIO;
++ if (!adapter->erp_thread) {
++ need = ZFCP_ERP_ACTION_NONE; /* marker for trace */
++ retval = -EIO;
++ goto out;
++ }
+
+ need = zfcp_erp_required_act(want, adapter, port, sdev);
+ if (!need)
--- /dev/null
+From 96d9270499471545048ed8a6d7f425a49762283d Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:46 +0200
+Subject: scsi: zfcp: fix missing REC trigger trace on terminate_rport_io early return
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit 96d9270499471545048ed8a6d7f425a49762283d upstream.
+
+get_device() and its internally used kobject_get() only return NULL if they
+get passed NULL as argument. zfcp_get_port_by_wwpn() loops over
+adapter->port_list so the iteration variable port is always non-NULL.
+Struct device is embedded in struct zfcp_port so &port->dev is always
+non-NULL. This is the argument to get_device(). However, if we get an
+fc_rport in terminate_rport_io() for which we cannot find a match within
+zfcp_get_port_by_wwpn(), the latter can return NULL. v2.6.30 commit
+70932935b61e ("[SCSI] zfcp: Fix oops when port disappears") introduced an
+early return without adding a trace record for this case. Even if we don't
+need recovery in this case, for debugging we should still see that our
+callback was invoked originally by scsi_transport_fc.
+
+Example trace record formatted with zfcpdbf from s390-tools:
+
+Timestamp : ...
+Area : REC
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1
+Tag : sctrpin SCSI terminate rport I/O, no zfcp port
+LUN : 0xffffffffffffffff none (invalid)
+WWPN : 0x<wwpn> WWPN
+D_ID : 0x<n_port_id> N_Port-ID
+Adapter status : 0x...
+Port status : 0xffffffff unknown (-1)
+LUN status : 0x00000000 none (invalid)
+Ready count : 0x...
+Running count : 0x...
+ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
+ERP need : 0xc0 ZFCP_ERP_ACTION_NONE
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Fixes: 70932935b61e ("[SCSI] zfcp: Fix oops when port disappears")
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_erp.c | 20 ++++++++++++++++++++
+ drivers/s390/scsi/zfcp_ext.h | 3 +++
+ drivers/s390/scsi/zfcp_scsi.c | 5 +++++
+ 3 files changed, 28 insertions(+)
+
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -282,6 +282,26 @@ static int zfcp_erp_action_enqueue(int w
+ return retval;
+ }
+
++void zfcp_erp_port_forced_no_port_dbf(char *id, struct zfcp_adapter *adapter,
++ u64 port_name, u32 port_id)
++{
++ unsigned long flags;
++ static /* don't waste stack */ struct zfcp_port tmpport;
++
++ write_lock_irqsave(&adapter->erp_lock, flags);
++ /* Stand-in zfcp port with fields just good enough for
++ * zfcp_dbf_rec_trig() and zfcp_dbf_set_common().
++ * Under lock because tmpport is static.
++ */
++ atomic_set(&tmpport.status, -1); /* unknown */
++ tmpport.wwpn = port_name;
++ tmpport.d_id = port_id;
++ zfcp_dbf_rec_trig(id, adapter, &tmpport, NULL,
++ ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
++ ZFCP_ERP_ACTION_NONE);
++ write_unlock_irqrestore(&adapter->erp_lock, flags);
++}
++
+ static int _zfcp_erp_adapter_reopen(struct zfcp_adapter *adapter,
+ int clear_mask, char *id)
+ {
+--- a/drivers/s390/scsi/zfcp_ext.h
++++ b/drivers/s390/scsi/zfcp_ext.h
+@@ -58,6 +58,9 @@ extern void zfcp_dbf_scsi_eh(char *tag,
+ /* zfcp_erp.c */
+ extern void zfcp_erp_set_adapter_status(struct zfcp_adapter *, u32);
+ extern void zfcp_erp_clear_adapter_status(struct zfcp_adapter *, u32);
++extern void zfcp_erp_port_forced_no_port_dbf(char *id,
++ struct zfcp_adapter *adapter,
++ u64 port_name, u32 port_id);
+ extern void zfcp_erp_adapter_reopen(struct zfcp_adapter *, int, char *);
+ extern void zfcp_erp_adapter_shutdown(struct zfcp_adapter *, int, char *);
+ extern void zfcp_erp_set_port_status(struct zfcp_port *, u32);
+--- a/drivers/s390/scsi/zfcp_scsi.c
++++ b/drivers/s390/scsi/zfcp_scsi.c
+@@ -603,6 +603,11 @@ static void zfcp_scsi_terminate_rport_io
+ if (port) {
+ zfcp_erp_port_forced_reopen(port, 0, "sctrpi1");
+ put_device(&port->dev);
++ } else {
++ zfcp_erp_port_forced_no_port_dbf(
++ "sctrpin", adapter,
++ rport->port_name /* zfcp_scsi_rport_register */,
++ rport->port_id /* zfcp_scsi_rport_register */);
+ }
+ }
+
--- /dev/null
+From d70aab55924b44f213fec2b900b095430b33eec6 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:47 +0200
+Subject: scsi: zfcp: fix missing REC trigger trace on terminate_rport_io for ERP_FAILED
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit d70aab55924b44f213fec2b900b095430b33eec6 upstream.
+
+For problem determination we always want to see when we were invoked on the
+terminate_rport_io callback whether we perform something or not.
+
+Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec:
+
+loose remote port
+
+t workqueue
+[s] zfcp_q_<dev> IRQ zfcperp<dev>
+
+=== ================== =================== ============================
+
+ 0 recv RSCN
+ q p.test_link_work
+ block rport
+ start fast_io_fail_tmo
+ send ADISC ELS
+ 4 recv ADISC fail
+ block zfcp_port
+ port forced reopen
+ send open port
+ 12 recv open port fail
+ q p.gid_pn_work
+ zfcp_erp_wakeup
+ (zfcp_erp_wait would return)
+ GID_PN fail
+
+Before this point, we got a SCSI trace with tag "sctrpi1" on fast_io_fail,
+e.g. with the typical 5 sec setting.
+
+ port.status |= ERP_FAILED
+
+If fast_io_fail_tmo triggers after this point, we missed a SCSI trace.
+
+ workqueue
+ fc_dl_<host>
+ ==================
+ 27 fc_timeout_fail_rport_io
+ fc_terminate_rport_io
+ zfcp_scsi_terminate_rport_io
+ zfcp_erp_port_forced_reopen
+ _zfcp_erp_port_forced_reopen
+ if (port.status & ERP_FAILED)
+ return;
+
+Therefore, write a trace before above early return.
+
+Example trace record formatted with zfcpdbf from s390-tools:
+
+Timestamp : ...
+Area : REC
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1 ZFCP_DBF_REC_TRIG
+Tag : sctrpi1 SCSI terminate rport I/O
+LUN : 0xffffffffffffffff none (invalid)
+WWPN : 0x<wwpn>
+D_ID : 0x<n_port_id>
+Adapter status : 0x...
+Port status : 0x...
+LUN status : 0x00000000 none (invalid)
+Ready count : 0x...
+Running count : 0x...
+ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
+ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_erp.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -41,9 +41,13 @@ enum zfcp_erp_steps {
+ * @ZFCP_ERP_ACTION_REOPEN_PORT_FORCED: Forced port recovery.
+ * @ZFCP_ERP_ACTION_REOPEN_ADAPTER: Adapter recovery.
+ * @ZFCP_ERP_ACTION_NONE: Eyecatcher pseudo flag to bitwise or-combine with
+- * either of the other enum values.
++ * either of the first four enum values.
+ * Used to indicate that an ERP action could not be
+ * set up despite a detected need for some recovery.
++ * @ZFCP_ERP_ACTION_FAILED: Eyecatcher pseudo flag to bitwise or-combine with
++ * either of the first four enum values.
++ * Used to indicate that ERP not needed because
++ * the object has ZFCP_STATUS_COMMON_ERP_FAILED.
+ */
+ enum zfcp_erp_act_type {
+ ZFCP_ERP_ACTION_REOPEN_LUN = 1,
+@@ -51,6 +55,7 @@ enum zfcp_erp_act_type {
+ ZFCP_ERP_ACTION_REOPEN_PORT_FORCED = 3,
+ ZFCP_ERP_ACTION_REOPEN_ADAPTER = 4,
+ ZFCP_ERP_ACTION_NONE = 0xc0,
++ ZFCP_ERP_ACTION_FAILED = 0xe0,
+ };
+
+ enum zfcp_erp_act_state {
+@@ -378,8 +383,12 @@ static void _zfcp_erp_port_forced_reopen
+ zfcp_erp_port_block(port, clear);
+ zfcp_scsi_schedule_rport_block(port);
+
+- if (atomic_read(&port->status) & ZFCP_STATUS_COMMON_ERP_FAILED)
++ if (atomic_read(&port->status) & ZFCP_STATUS_COMMON_ERP_FAILED) {
++ zfcp_dbf_rec_trig(id, port->adapter, port, NULL,
++ ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
++ ZFCP_ERP_ACTION_FAILED);
+ return;
++ }
+
+ zfcp_erp_action_enqueue(ZFCP_ERP_ACTION_REOPEN_PORT_FORCED,
+ port->adapter, port, NULL, id, 0);
--- /dev/null
+From df30781699f53e4fd4c494c6f7dd16e3d5c21d30 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:43 +0200
+Subject: scsi: zfcp: fix missing SCSI trace for result of eh_host_reset_handler
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit df30781699f53e4fd4c494c6f7dd16e3d5c21d30 upstream.
+
+For problem determination we need to see whether and why we were successful
+or not. This allows deduction of scsi_eh escalation.
+
+Example trace record formatted with zfcpdbf from s390-tools:
+
+Timestamp : ...
+Area : SCSI
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1
+Tag : schrh_r SCSI host reset handler result
+Request ID : 0x0000000000000000 none (invalid)
+SCSI ID : 0xffffffff none (invalid)
+SCSI LUN : 0xffffffff none (invalid)
+SCSI LUN high : 0xffffffff none (invalid)
+SCSI result : 0x00002002 field re-used for midlayer value: SUCCESS
+ or in other cases: 0x2009 == FAST_IO_FAIL
+SCSI retries : 0xff none (invalid)
+SCSI allowed : 0xff none (invalid)
+SCSI scribble : 0xffffffffffffffff none (invalid)
+SCSI opcode : ffffffff ffffffff ffffffff ffffffff none (invalid)
+FCP rsp inf cod: 0xff none (invalid)
+FCP rsp IU : 00000000 00000000 00000000 00000000 none (invalid)
+ 00000000 00000000
+
+v2.6.35 commit a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from
+fc_block_scsi_eh to scsi eh") introduced the first return with something
+other than the previously hardcoded single SUCCESS return path.
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Fixes: a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Jens Remus <jremus@linux.ibm.com>
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_dbf.c | 40 ++++++++++++++++++++++++++++++++++++++++
+ drivers/s390/scsi/zfcp_ext.h | 2 ++
+ drivers/s390/scsi/zfcp_scsi.c | 11 ++++++-----
+ 3 files changed, 48 insertions(+), 5 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -625,6 +625,46 @@ void zfcp_dbf_scsi(char *tag, int level,
+ spin_unlock_irqrestore(&dbf->scsi_lock, flags);
+ }
+
++/**
++ * zfcp_dbf_scsi_eh() - Trace event for special cases of scsi_eh callbacks.
++ * @tag: Identifier for event.
++ * @adapter: Pointer to zfcp adapter as context for this event.
++ * @scsi_id: SCSI ID/target to indicate scope of task management function (TMF).
++ * @ret: Return value of calling function.
++ *
++ * This SCSI trace variant does not depend on any of:
++ * scsi_cmnd, zfcp_fsf_req, scsi_device.
++ */
++void zfcp_dbf_scsi_eh(char *tag, struct zfcp_adapter *adapter,
++ unsigned int scsi_id, int ret)
++{
++ struct zfcp_dbf *dbf = adapter->dbf;
++ struct zfcp_dbf_scsi *rec = &dbf->scsi_buf;
++ unsigned long flags;
++ static int const level = 1;
++
++ if (unlikely(!debug_level_enabled(adapter->dbf->scsi, level)))
++ return;
++
++ spin_lock_irqsave(&dbf->scsi_lock, flags);
++ memset(rec, 0, sizeof(*rec));
++
++ memcpy(rec->tag, tag, ZFCP_DBF_TAG_LEN);
++ rec->id = ZFCP_DBF_SCSI_CMND;
++ rec->scsi_result = ret; /* re-use field, int is 4 bytes and fits */
++ rec->scsi_retries = ~0;
++ rec->scsi_allowed = ~0;
++ rec->fcp_rsp_info = ~0;
++ rec->scsi_id = scsi_id;
++ rec->scsi_lun = (u32)ZFCP_DBF_INVALID_LUN;
++ rec->scsi_lun_64_hi = (u32)(ZFCP_DBF_INVALID_LUN >> 32);
++ rec->host_scribble = ~0;
++ memset(rec->scsi_opcode, 0xff, ZFCP_DBF_SCSI_OPCODE);
++
++ debug_event(dbf->scsi, level, rec, sizeof(*rec));
++ spin_unlock_irqrestore(&dbf->scsi_lock, flags);
++}
++
+ static debug_info_t *zfcp_dbf_reg(const char *name, int size, int rec_size)
+ {
+ struct debug_info *d;
+--- a/drivers/s390/scsi/zfcp_ext.h
++++ b/drivers/s390/scsi/zfcp_ext.h
+@@ -52,6 +52,8 @@ extern void zfcp_dbf_san_res(char *, str
+ extern void zfcp_dbf_san_in_els(char *, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_scsi(char *, int, struct scsi_cmnd *,
+ struct zfcp_fsf_req *);
++extern void zfcp_dbf_scsi_eh(char *tag, struct zfcp_adapter *adapter,
++ unsigned int scsi_id, int ret);
+
+ /* zfcp_erp.c */
+ extern void zfcp_erp_set_adapter_status(struct zfcp_adapter *, u32);
+--- a/drivers/s390/scsi/zfcp_scsi.c
++++ b/drivers/s390/scsi/zfcp_scsi.c
+@@ -322,15 +322,16 @@ static int zfcp_scsi_eh_host_reset_handl
+ {
+ struct zfcp_scsi_dev *zfcp_sdev = sdev_to_zfcp(scpnt->device);
+ struct zfcp_adapter *adapter = zfcp_sdev->port->adapter;
+- int ret;
++ int ret = SUCCESS, fc_ret;
+
+ zfcp_erp_adapter_reopen(adapter, 0, "schrh_1");
+ zfcp_erp_wait(adapter);
+- ret = fc_block_scsi_eh(scpnt);
+- if (ret)
+- return ret;
++ fc_ret = fc_block_scsi_eh(scpnt);
++ if (fc_ret)
++ ret = fc_ret;
+
+- return SUCCESS;
++ zfcp_dbf_scsi_eh("schrh_r", adapter, ~0, ret);
++ return ret;
+ }
+
+ struct scsi_transport_template *zfcp_scsi_transport_template;
--- /dev/null
+From 81979ae63e872ef650a7197f6ce6590059d37172 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+Date: Thu, 17 May 2018 19:14:44 +0200
+Subject: scsi: zfcp: fix missing SCSI trace for retry of abort / scsi_eh TMF
+
+From: Steffen Maier <maier@linux.ibm.com>
+
+commit 81979ae63e872ef650a7197f6ce6590059d37172 upstream.
+
+We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to
+zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the start of
+our eh callback and an actual send/recv of an abort / TMF request. In order
+to see the temporal sequence including any abort / TMF send retries, add a
+trace before the above two blocking functions. This supports problem
+determination with scsi_eh and parallel zfcp ERP.
+
+No need to explicitly trace the beginning of our eh callback, since we
+typically can send an abort / TMF and see its HBA response (in the worst
+case, it's a pseudo response on dismiss all of adapter recovery, e.g. due to
+an FSF request timeout [fsrth_1] of the abort / TMF). If we cannot send, we
+now get a trace record for the first "abrt_wt" or "[lt]r_wait" which denotes
+almost the beginning of the callback.
+
+No need to explicitly trace the wakeup after the above two blocking
+functions because the next retry loop causes another trace in any case and
+that is sufficient.
+
+Example trace records formatted with zfcpdbf from s390-tools:
+
+Timestamp : ...
+Area : SCSI
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1
+Tag : abrt_wt abort, before zfcp_erp_wait()
+Request ID : 0x0000000000000000 none (invalid)
+SCSI ID : 0x<scsi_id>
+SCSI LUN : 0x<scsi_lun>
+SCSI LUN high : 0x<scsi_lun_high>
+SCSI result : 0x<scsi_result_of_cmd_to_be_aborted>
+SCSI retries : 0x<retries_of_cmd_to_be_aborted>
+SCSI allowed : 0x<allowed_retries_of_cmd_to_be_aborted>
+SCSI scribble : 0x<req_id_of_cmd_to_be_aborted>
+SCSI opcode : <CDB_of_cmd_to_be_aborted>
+FCP rsp inf cod: 0x.. none (invalid)
+FCP rsp IU : ... none (invalid)
+
+Timestamp : ...
+Area : SCSI
+Subarea : 00
+Level : 1
+Exception : -
+CPU ID : ..
+Caller : 0x...
+Record ID : 1
+Tag : lr_wait LUN reset, before zfcp_erp_wait()
+Request ID : 0x0000000000000000 none (invalid)
+SCSI ID : 0x<scsi_id>
+SCSI LUN : 0x<scsi_lun>
+SCSI LUN high : 0x<scsi_lun_high>
+SCSI result : 0x... unrelated
+SCSI retries : 0x.. unrelated
+SCSI allowed : 0x.. unrelated
+SCSI scribble : 0x... unrelated
+SCSI opcode : ... unrelated
+FCP rsp inf cod: 0x.. none (invalid)
+FCP rsp IU : ... none (invalid)
+
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Fixes: 63caf367e1c9 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
+Fixes: af4de36d911a ("[SCSI] zfcp: Block scsi_eh thread for rport state BLOCKED")
+Cc: <stable@vger.kernel.org> #2.6.38+
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_scsi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/s390/scsi/zfcp_scsi.c
++++ b/drivers/s390/scsi/zfcp_scsi.c
+@@ -180,6 +180,7 @@ static int zfcp_scsi_eh_abort_handler(st
+ if (abrt_req)
+ break;
+
++ zfcp_dbf_scsi_abort("abrt_wt", scpnt, NULL);
+ zfcp_erp_wait(adapter);
+ ret = fc_block_scsi_eh(scpnt);
+ if (ret) {
+@@ -276,6 +277,7 @@ static int zfcp_task_mgmt_function(struc
+ if (fsf_req)
+ break;
+
++ zfcp_dbf_scsi_devreset("wait", scpnt, tm_flags, NULL);
+ zfcp_erp_wait(adapter);
+ ret = fc_block_scsi_eh(scpnt);
+ if (ret) {
btrfs-fix-return-value-on-rename-exchange-failure.patch
btrfs-fix-unexpected-cow-in-run_delalloc_nocow.patch
iio-buffer-make-length-types-match-kfifo-types.patch
+scsi-qla2xxx-fix-setting-lower-transfer-speed-if-gpsc-fails.patch
+scsi-qla2xxx-mask-off-scope-bits-in-retry-delay.patch
+scsi-zfcp-fix-missing-scsi-trace-for-result-of-eh_host_reset_handler.patch
+scsi-zfcp-fix-missing-scsi-trace-for-retry-of-abort-scsi_eh-tmf.patch
+scsi-zfcp-fix-misleading-rec-trigger-trace-where-erp_action-setup-failed.patch
+scsi-zfcp-fix-missing-rec-trigger-trace-on-terminate_rport_io-early-return.patch
+scsi-zfcp-fix-missing-rec-trigger-trace-on-terminate_rport_io-for-erp_failed.patch
+scsi-zfcp-fix-missing-rec-trigger-trace-for-all-objects-in-erp_failed.patch
+scsi-zfcp-fix-missing-rec-trigger-trace-on-enqueue-without-erp-thread.patch
+linvdimm-pmem-preserve-read-only-setting-for-pmem-devices.patch
+clk-at91-pll-recalc_rate-now-using-cached-mul-and-div-values.patch
+md-fix-two-problems-with-setting-the-re-add-device-state.patch
+rpmsg-smd-do-not-use-mananged-resources-for-endpoints-and-channels.patch
+ubi-fastmap-cancel-work-upon-detach.patch
+ubi-fastmap-correctly-handle-interrupted-erasures-in-eba.patch
+ubifs-fix-potential-integer-overflow-in-allocation.patch
+backlight-as3711_bl-fix-device-tree-node-lookup.patch
+backlight-max8925_bl-fix-device-tree-node-lookup.patch
+backlight-tps65217_bl-fix-device-tree-node-lookup.patch
+mfd-intel-lpss-program-remap-register-in-pio-mode.patch
+perf-tools-fix-symbol-and-object-code-resolution-for-vdso32-and-vdsox32.patch
+perf-intel-pt-fix-sync_switch-intel_pt_ss_not_tracing.patch
+perf-intel-pt-fix-decoding-to-accept-cbr-between-fup-and-corresponding-tip.patch
+perf-intel-pt-fix-mtc-timing-after-overflow.patch
+perf-intel-pt-fix-unexpected-indirect-branch-error.patch
+perf-intel-pt-fix-packet-decoding-of-cyc-packets.patch
+media-v4l2-compat-ioctl32-prevent-go-past-max-size.patch
+media-cx231xx-add-support-for-avermedia-dvd-ezmaker-7.patch
+media-dvb_frontend-fix-locking-issues-at-dvb_frontend_get_event.patch
+nfsd-restrict-rd_maxcount-to-svc_max_payload-in-nfsd_encode_readdir.patch
+nfsv4-fix-possible-1-byte-stack-overflow-in-nfs_idmap_read_and_verify_message.patch
+nfsv4-revert-commit-5f83d86cf531d-nfsv4.x-fix-wraparound-issues.patch
+video-uvesafb-fix-integer-overflow-in-allocation.patch
+input-elan_i2c-add-elan0618-lenovo-v330-15ikb-acpi-id.patch
+pwm-lpss-platform-save-restore-the-ctrl-register-over-a-suspend-resume.patch
+rbd-flush-rbd_dev-watch_dwork-after-watch-is-unregistered.patch
+mm-fix-devmem_is_allowed-for-sub-page-system-ram-intersections.patch
+xen-remove-unnecessary-bug_on-from-__unbind_from_irq.patch
+udf-detect-incorrect-directory-size.patch
+input-elan_i2c_smbus-fix-more-potential-stack-buffer-overflows.patch
+input-elantech-enable-middle-button-of-touchpads-on-thinkpad-p52.patch
+input-elantech-fix-v4-report-decoding-for-module-with-middle-key.patch
+alsa-hda-realtek-fix-pop-noise-on-lenovo-p50-co.patch
+alsa-hda-realtek-add-a-quirk-for-fsc-esprimo-u9210.patch
--- /dev/null
+From 6e7d80161066c99d12580d1b985cb1408bb58cf1 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Wed, 16 May 2018 22:17:03 +0200
+Subject: ubi: fastmap: Cancel work upon detach
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 6e7d80161066c99d12580d1b985cb1408bb58cf1 upstream.
+
+Ben Hutchings pointed out that 29b7a6fa1ec0 ("ubi: fastmap: Don't flush
+fastmap work on detach") does not really fix the problem, it just
+reduces the risk to hit the race window where fastmap work races against
+free()'ing ubi->volumes[].
+
+The correct approach is making sure that no more fastmap work is in
+progress before we free ubi data structures.
+So we cancel fastmap work right after the ubi background thread is
+stopped.
+By setting ubi->thread_enabled to zero we make sure that no further work
+tries to wake the thread.
+
+Fixes: 29b7a6fa1ec0 ("ubi: fastmap: Don't flush fastmap work on detach")
+Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
+Cc: stable@vger.kernel.org
+Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Cc: Martin Townsend <mtownsend1973@gmail.com>
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/build.c | 3 +++
+ drivers/mtd/ubi/wl.c | 4 +---
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/ubi/build.c
++++ b/drivers/mtd/ubi/build.c
+@@ -1137,6 +1137,9 @@ int ubi_detach_mtd_dev(int ubi_num, int
+ */
+ get_device(&ubi->dev);
+
++#ifdef CONFIG_MTD_UBI_FASTMAP
++ cancel_work_sync(&ubi->fm_work);
++#endif
+ ubi_debugfs_exit_dev(ubi);
+ uif_close(ubi);
+
+--- a/drivers/mtd/ubi/wl.c
++++ b/drivers/mtd/ubi/wl.c
+@@ -1505,6 +1505,7 @@ int ubi_thread(void *u)
+ }
+
+ dbg_wl("background thread \"%s\" is killed", ubi->bgt_name);
++ ubi->thread_enabled = 0;
+ return 0;
+ }
+
+@@ -1514,9 +1515,6 @@ int ubi_thread(void *u)
+ */
+ static void shutdown_work(struct ubi_device *ubi)
+ {
+-#ifdef CONFIG_MTD_UBI_FASTMAP
+- flush_work(&ubi->fm_work);
+-#endif
+ while (!list_empty(&ubi->works)) {
+ struct ubi_work *wrk;
+
--- /dev/null
+From 781932375ffc6411713ee0926ccae8596ed0261c Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Mon, 28 May 2018 22:04:32 +0200
+Subject: ubi: fastmap: Correctly handle interrupted erasures in EBA
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
+
+Fastmap cannot track the LEB unmap operation, therefore it can
+happen that after an interrupted erasure the mapping still looks
+good from Fastmap's point of view, while reading from the PEB will
+cause an ECC error and confuses the upper layer.
+
+Instead of teaching users of UBI how to deal with that, we read back
+the VID header and check for errors. If the PEB is empty or shows ECC
+errors we fixup the mapping and schedule the PEB for erasure.
+
+Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
+Cc: <stable@vger.kernel.org>
+Reported-by: martin bayern <Martinbayern@outlook.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/eba.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 89 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/ubi/eba.c
++++ b/drivers/mtd/ubi/eba.c
+@@ -490,6 +490,82 @@ out_unlock:
+ return err;
+ }
+
++#ifdef CONFIG_MTD_UBI_FASTMAP
++/**
++ * check_mapping - check and fixup a mapping
++ * @ubi: UBI device description object
++ * @vol: volume description object
++ * @lnum: logical eraseblock number
++ * @pnum: physical eraseblock number
++ *
++ * Checks whether a given mapping is valid. Fastmap cannot track LEB unmap
++ * operations, if such an operation is interrupted the mapping still looks
++ * good, but upon first read an ECC is reported to the upper layer.
++ * Normaly during the full-scan at attach time this is fixed, for Fastmap
++ * we have to deal with it while reading.
++ * If the PEB behind a LEB shows this symthom we change the mapping to
++ * %UBI_LEB_UNMAPPED and schedule the PEB for erasure.
++ *
++ * Returns 0 on success, negative error code in case of failure.
++ */
++static int check_mapping(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
++ int *pnum)
++{
++ int err;
++ struct ubi_vid_io_buf *vidb;
++
++ if (!ubi->fast_attach)
++ return 0;
++
++ vidb = ubi_alloc_vid_buf(ubi, GFP_NOFS);
++ if (!vidb)
++ return -ENOMEM;
++
++ err = ubi_io_read_vid_hdr(ubi, *pnum, vidb, 0);
++ if (err > 0 && err != UBI_IO_BITFLIPS) {
++ int torture = 0;
++
++ switch (err) {
++ case UBI_IO_FF:
++ case UBI_IO_FF_BITFLIPS:
++ case UBI_IO_BAD_HDR:
++ case UBI_IO_BAD_HDR_EBADMSG:
++ break;
++ default:
++ ubi_assert(0);
++ }
++
++ if (err == UBI_IO_BAD_HDR_EBADMSG || err == UBI_IO_FF_BITFLIPS)
++ torture = 1;
++
++ down_read(&ubi->fm_eba_sem);
++ vol->eba_tbl->entries[lnum].pnum = UBI_LEB_UNMAPPED;
++ up_read(&ubi->fm_eba_sem);
++ ubi_wl_put_peb(ubi, vol->vol_id, lnum, *pnum, torture);
++
++ *pnum = UBI_LEB_UNMAPPED;
++ } else if (err < 0) {
++ ubi_err(ubi, "unable to read VID header back from PEB %i: %i",
++ *pnum, err);
++
++ goto out_free;
++ }
++
++ err = 0;
++
++out_free:
++ ubi_free_vid_buf(vidb);
++
++ return err;
++}
++#else
++static int check_mapping(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
++ int *pnum)
++{
++ return 0;
++}
++#endif
++
+ /**
+ * ubi_eba_read_leb - read data.
+ * @ubi: UBI device description object
+@@ -522,7 +598,13 @@ int ubi_eba_read_leb(struct ubi_device *
+ return err;
+
+ pnum = vol->eba_tbl->entries[lnum].pnum;
+- if (pnum < 0) {
++ if (pnum >= 0) {
++ err = check_mapping(ubi, vol, lnum, &pnum);
++ if (err < 0)
++ goto out_unlock;
++ }
++
++ if (pnum == UBI_LEB_UNMAPPED) {
+ /*
+ * The logical eraseblock is not mapped, fill the whole buffer
+ * with 0xFF bytes. The exception is static volumes for which
+@@ -931,6 +1013,12 @@ int ubi_eba_write_leb(struct ubi_device
+
+ pnum = vol->eba_tbl->entries[lnum].pnum;
+ if (pnum >= 0) {
++ err = check_mapping(ubi, vol, lnum, &pnum);
++ if (err < 0)
++ goto out;
++ }
++
++ if (pnum >= 0) {
+ dbg_eba("write %d bytes at offset %d of LEB %d:%d, PEB %d",
+ len, offset, vol_id, lnum, pnum);
+
--- /dev/null
+From 353748a359f1821ee934afc579cf04572406b420 Mon Sep 17 00:00:00 2001
+From: Silvio Cesare <silvio.cesare@gmail.com>
+Date: Fri, 4 May 2018 13:44:02 +1000
+Subject: UBIFS: Fix potential integer overflow in allocation
+
+From: Silvio Cesare <silvio.cesare@gmail.com>
+
+commit 353748a359f1821ee934afc579cf04572406b420 upstream.
+
+There is potential for the size and len fields in ubifs_data_node to be
+too large causing either a negative value for the length fields or an
+integer overflow leading to an incorrect memory allocation. Likewise,
+when the len field is small, an integer underflow may occur.
+
+Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com>
+Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ubifs/journal.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ubifs/journal.c
++++ b/fs/ubifs/journal.c
+@@ -1265,7 +1265,7 @@ static int recomp_data_node(const struct
+ int err, len, compr_type, out_len;
+
+ out_len = le32_to_cpu(dn->size);
+- buf = kmalloc(out_len * WORST_COMPR_FACTOR, GFP_NOFS);
++ buf = kmalloc_array(out_len, WORST_COMPR_FACTOR, GFP_NOFS);
+ if (!buf)
+ return -ENOMEM;
+
--- /dev/null
+From fa65653e575fbd958bdf5fb9c4a71a324e39510d Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Wed, 13 Jun 2018 12:09:22 +0200
+Subject: udf: Detect incorrect directory size
+
+From: Jan Kara <jack@suse.cz>
+
+commit fa65653e575fbd958bdf5fb9c4a71a324e39510d upstream.
+
+Detect when a directory entry is (possibly partially) beyond directory
+size and return EIO in that case since it means the filesystem is
+corrupted. Otherwise directory operations can further corrupt the
+directory and possibly also oops the kernel.
+
+CC: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
+CC: stable@vger.kernel.org
+Reported-and-tested-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/udf/directory.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/udf/directory.c
++++ b/fs/udf/directory.c
+@@ -150,6 +150,9 @@ struct fileIdentDesc *udf_fileident_read
+ sizeof(struct fileIdentDesc));
+ }
+ }
++ /* Got last entry outside of dir size - fs is corrupted! */
++ if (*nf_pos > dir->i_size)
++ return NULL;
+ return fi;
+ }
+
--- /dev/null
+From 9f645bcc566a1e9f921bdae7528a01ced5bc3713 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Fri, 11 May 2018 18:24:12 +1000
+Subject: video: uvesafb: Fix integer overflow in allocation
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 9f645bcc566a1e9f921bdae7528a01ced5bc3713 upstream.
+
+cmap->len can get close to INT_MAX/2, allowing for an integer overflow in
+allocation. This uses kmalloc_array() instead to catch the condition.
+
+Reported-by: Dr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
+Fixes: 8bdb3a2d7df48 ("uvesafb: the driver core")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/uvesafb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/uvesafb.c
++++ b/drivers/video/fbdev/uvesafb.c
+@@ -1059,7 +1059,8 @@ static int uvesafb_setcmap(struct fb_cma
+ info->cmap.len || cmap->start < info->cmap.start)
+ return -EINVAL;
+
+- entries = kmalloc(sizeof(*entries) * cmap->len, GFP_KERNEL);
++ entries = kmalloc_array(cmap->len, sizeof(*entries),
++ GFP_KERNEL);
+ if (!entries)
+ return -ENOMEM;
+
--- /dev/null
+From eef04c7b3786ff0c9cb1019278b6c6c2ea0ad4ff Mon Sep 17 00:00:00 2001
+From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Date: Thu, 21 Jun 2018 13:29:44 -0400
+Subject: xen: Remove unnecessary BUG_ON from __unbind_from_irq()
+
+From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+
+commit eef04c7b3786ff0c9cb1019278b6c6c2ea0ad4ff upstream.
+
+Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding
+MSIs") fixed a couple of errors in error cleanup path of
+xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to
+__unbind_from_irq() with an unbound irq, which would result in
+triggering the BUG_ON there.
+
+Since there is really no reason for the BUG_ON (xen_free_irq() can
+operate on unbound irqs) we can remove it.
+
+Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/events/events_base.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/xen/events/events_base.c
++++ b/drivers/xen/events/events_base.c
+@@ -637,8 +637,6 @@ static void __unbind_from_irq(unsigned i
+ xen_irq_info_cleanup(info);
+ }
+
+- BUG_ON(info_for_irq(irq)->type == IRQT_UNBOUND);
+-
+ xen_free_irq(irq);
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
