--- /dev/null
+From 176a7fca81c5090a7240664e3002c106d296bf31 Mon Sep 17 00:00:00 2001
+From: Jian-Hong Pan <jian-hong@endlessm.com>
+Date: Mon, 30 Dec 2019 16:30:45 +0800
+Subject: platform/x86: asus-wmi: Fix keyboard brightness cannot be set to 0
+
+From: Jian-Hong Pan <jian-hong@endlessm.com>
+
+commit 176a7fca81c5090a7240664e3002c106d296bf31 upstream.
+
+Some of ASUS laptops like UX431FL keyboard backlight cannot be set to
+brightness 0. According to ASUS' information, the brightness should be
+0x80 ~ 0x83. This patch fixes it by following the logic.
+
+Fixes: e9809c0b9670 ("asus-wmi: add keyboard backlight support")
+Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
+Reviewed-by: Daniel Drake <drake@endlessm.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/platform/x86/asus-wmi.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/drivers/platform/x86/asus-wmi.c
++++ b/drivers/platform/x86/asus-wmi.c
+@@ -463,13 +463,7 @@ static void kbd_led_update(struct work_s
+
+ asus = container_of(work, struct asus_wmi, kbd_led_work);
+
+- /*
+- * bits 0-2: level
+- * bit 7: light on/off
+- */
+- if (asus->kbd_led_wk > 0)
+- ctrl_param = 0x80 | (asus->kbd_led_wk & 0x7F);
+-
++ ctrl_param = 0x80 | (asus->kbd_led_wk & 0x7F);
+ asus_wmi_set_devstate(ASUS_WMI_DEVID_KBD_BACKLIGHT, ctrl_param, NULL);
+ led_classdev_notify_brightness_hw_changed(&asus->kbd_led, asus->kbd_led_wk);
+ }
--- /dev/null
+From 6ae01050e49f0080ae30575d9b45a6d4a3d7ee23 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 6 Jan 2020 15:42:18 +0100
+Subject: platform/x86: GPD pocket fan: Use default values when wrong modparams are given
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 6ae01050e49f0080ae30575d9b45a6d4a3d7ee23 upstream.
+
+Use our default values when wrong module-parameters are given, instead of
+refusing to load. Refusing to load leaves the fan at the BIOS default
+setting, which is "Off". The CPU's thermal throttling should protect the
+system from damage, but not-loading is really not the best fallback in this
+case.
+
+This commit fixes this by re-setting module-parameter values to their
+defaults if they are out of range, instead of failing the probe with
+-EINVAL.
+
+Cc: stable@vger.kernel.org
+Cc: Jason Anderson <jasona.594@gmail.com>
+Reported-by: Jason Anderson <jasona.594@gmail.com>
+Fixes: 594ce6db326e ("platform/x86: GPD pocket fan: Use a min-speed of 2 while charging")
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/platform/x86/gpd-pocket-fan.c | 25 +++++++++++++++++++------
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+--- a/drivers/platform/x86/gpd-pocket-fan.c
++++ b/drivers/platform/x86/gpd-pocket-fan.c
+@@ -16,17 +16,27 @@
+
+ #define MAX_SPEED 3
+
+-static int temp_limits[3] = { 55000, 60000, 65000 };
++#define TEMP_LIMIT0_DEFAULT 55000
++#define TEMP_LIMIT1_DEFAULT 60000
++#define TEMP_LIMIT2_DEFAULT 65000
++
++#define HYSTERESIS_DEFAULT 3000
++
++#define SPEED_ON_AC_DEFAULT 2
++
++static int temp_limits[3] = {
++ TEMP_LIMIT0_DEFAULT, TEMP_LIMIT1_DEFAULT, TEMP_LIMIT2_DEFAULT,
++};
+ module_param_array(temp_limits, int, NULL, 0444);
+ MODULE_PARM_DESC(temp_limits,
+ "Millicelsius values above which the fan speed increases");
+
+-static int hysteresis = 3000;
++static int hysteresis = HYSTERESIS_DEFAULT;
+ module_param(hysteresis, int, 0444);
+ MODULE_PARM_DESC(hysteresis,
+ "Hysteresis in millicelsius before lowering the fan speed");
+
+-static int speed_on_ac = 2;
++static int speed_on_ac = SPEED_ON_AC_DEFAULT;
+ module_param(speed_on_ac, int, 0444);
+ MODULE_PARM_DESC(speed_on_ac,
+ "minimum fan speed to allow when system is powered by AC");
+@@ -120,18 +130,21 @@ static int gpd_pocket_fan_probe(struct p
+ if (temp_limits[i] < 40000 || temp_limits[i] > 70000) {
+ dev_err(&pdev->dev, "Invalid temp-limit %d (must be between 40000 and 70000)\n",
+ temp_limits[i]);
+- return -EINVAL;
++ temp_limits[0] = TEMP_LIMIT0_DEFAULT;
++ temp_limits[1] = TEMP_LIMIT1_DEFAULT;
++ temp_limits[2] = TEMP_LIMIT2_DEFAULT;
++ break;
+ }
+ }
+ if (hysteresis < 1000 || hysteresis > 10000) {
+ dev_err(&pdev->dev, "Invalid hysteresis %d (must be between 1000 and 10000)\n",
+ hysteresis);
+- return -EINVAL;
++ hysteresis = HYSTERESIS_DEFAULT;
+ }
+ if (speed_on_ac < 0 || speed_on_ac > MAX_SPEED) {
+ dev_err(&pdev->dev, "Invalid speed_on_ac %d (must be between 0 and 3)\n",
+ speed_on_ac);
+- return -EINVAL;
++ speed_on_ac = SPEED_ON_AC_DEFAULT;
+ }
+
+ fan = devm_kzalloc(&pdev->dev, sizeof(*fan), GFP_KERNEL);
--- /dev/null
+From 529244bd1afc102ab164429d338d310d5d65e60d Mon Sep 17 00:00:00 2001
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+Date: Wed, 8 Jan 2020 17:21:32 -0800
+Subject: scsi: enclosure: Fix stale device oops with hot replug
+
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+
+commit 529244bd1afc102ab164429d338d310d5d65e60d upstream.
+
+Doing an add/remove/add on a SCSI device in an enclosure leads to an oops
+caused by poisoned values in the enclosure device list pointers. The
+reason is because we are keeping the enclosure device across the enclosed
+device add/remove/add but the current code is doing a
+device_add/device_del/device_add on it. This is the wrong thing to do in
+sysfs, so fix it by not doing a device_del on the enclosure device simply
+because of a hot remove of the drive in the slot.
+
+[mkp: added missing email addresses]
+
+Fixes: 43d8eb9cfd0a ("[SCSI] ses: add support for enclosure component hot removal")
+Link: https://lore.kernel.org/r/1578532892.3852.10.camel@HansenPartnership.com
+Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
+Reported-by: Luo Jiaxing <luojiaxing@huawei.com>
+Tested-by: John Garry <john.garry@huawei.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/enclosure.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/misc/enclosure.c
++++ b/drivers/misc/enclosure.c
+@@ -419,10 +419,9 @@ int enclosure_remove_device(struct enclo
+ cdev = &edev->component[i];
+ if (cdev->dev == dev) {
+ enclosure_remove_links(cdev);
+- device_del(&cdev->cdev);
+ put_device(dev);
+ cdev->dev = NULL;
+- return device_add(&cdev->cdev);
++ return 0;
+ }
+ }
+ return -ENODEV;
--- /dev/null
+From 465f4edaecc6c37f81349233e84d46246bcac11a Mon Sep 17 00:00:00 2001
+From: Xiang Chen <chenxiang66@hisilicon.com>
+Date: Thu, 9 Jan 2020 09:12:24 +0800
+Subject: scsi: sd: Clear sdkp->protection_type if disk is reformatted without PI
+
+From: Xiang Chen <chenxiang66@hisilicon.com>
+
+commit 465f4edaecc6c37f81349233e84d46246bcac11a upstream.
+
+If an attached disk with protection information enabled is reformatted
+to Type 0 the revalidation code does not clear the original protection
+type and subsequent accesses will keep setting RDPROTECT/WRPROTECT.
+
+Set the protection type to 0 if the disk reports PROT_EN=0 in READ
+CAPACITY(16).
+
+[mkp: commit desc]
+
+Fixes: fe542396da73 ("[SCSI] sd: Ensure we correctly disable devices with unknown protection type")
+Link: https://lore.kernel.org/r/1578532344-101668-1-git-send-email-chenxiang66@hisilicon.com
+Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sd.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -2195,8 +2195,10 @@ static int sd_read_protection_type(struc
+ u8 type;
+ int ret = 0;
+
+- if (scsi_device_protection(sdp) == 0 || (buffer[12] & 1) == 0)
++ if (scsi_device_protection(sdp) == 0 || (buffer[12] & 1) == 0) {
++ sdkp->protection_type = 0;
+ return ret;
++ }
+
+ type = ((buffer[12] >> 1) & 7) + 1; /* P_TYPE 0 = Type 1 */
+
btrfs-simplify-inode-locking-for-rwf_nowait.patch
rdma-mlx5-return-proper-error-value.patch
rdma-srpt-report-the-scsi-residual-to-the-initiator.patch
+scsi-enclosure-fix-stale-device-oops-with-hot-replug.patch
+scsi-sd-clear-sdkp-protection_type-if-disk-is-reformatted-without-pi.patch
+platform-x86-asus-wmi-fix-keyboard-brightness-cannot-be-set-to-0.patch
+platform-x86-gpd-pocket-fan-use-default-values-when-wrong-modparams-are-given.patch
+xprtrdma-fix-completion-wait-during-device-removal.patch
--- /dev/null
+From 13cb886c591f341a8759f175292ddf978ef903a1 Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Fri, 3 Jan 2020 11:52:17 -0500
+Subject: xprtrdma: Fix completion wait during device removal
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit 13cb886c591f341a8759f175292ddf978ef903a1 upstream.
+
+I've found that on occasion, "rmmod <dev>" will hang while if an NFS
+is under load.
+
+Ensure that ri_remove_done is initialized only just before the
+transport is woken up to force a close. This avoids the completion
+possibly getting initialized again while the CM event handler is
+waiting for a wake-up.
+
+Fixes: bebd031866ca ("xprtrdma: Support unplugging an HCA from under an NFS mount")
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/xprtrdma/verbs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sunrpc/xprtrdma/verbs.c
++++ b/net/sunrpc/xprtrdma/verbs.c
+@@ -248,6 +248,7 @@ rpcrdma_conn_upcall(struct rdma_cm_id *i
+ ia->ri_device->name,
+ rpcrdma_addrstr(xprt), rpcrdma_portstr(xprt));
+ #endif
++ init_completion(&ia->ri_remove_done);
+ set_bit(RPCRDMA_IAF_REMOVING, &ia->ri_flags);
+ ep->rep_connected = -ENODEV;
+ xprt_force_disconnect(&xprt->rx_xprt);
+@@ -306,7 +307,6 @@ rpcrdma_create_id(struct rpcrdma_xprt *x
+ trace_xprtrdma_conn_start(xprt);
+
+ init_completion(&ia->ri_done);
+- init_completion(&ia->ri_remove_done);
+
+ id = rdma_create_id(xprt->rx_xprt.xprt_net, rpcrdma_conn_upcall,
+ xprt, RDMA_PS_TCP, IB_QPT_RC);