]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 16 Jan 2020 10:20:48 +0000 (11:20 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 16 Jan 2020 10:20:48 +0000 (11:20 +0100)
added patches:
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
scsi-enclosure-fix-stale-device-oops-with-hot-replug.patch
scsi-sd-clear-sdkp-protection_type-if-disk-is-reformatted-without-pi.patch
xprtrdma-fix-completion-wait-during-device-removal.patch

queue-4.19/platform-x86-asus-wmi-fix-keyboard-brightness-cannot-be-set-to-0.patch [new file with mode: 0644]
queue-4.19/platform-x86-gpd-pocket-fan-use-default-values-when-wrong-modparams-are-given.patch [new file with mode: 0644]
queue-4.19/scsi-enclosure-fix-stale-device-oops-with-hot-replug.patch [new file with mode: 0644]
queue-4.19/scsi-sd-clear-sdkp-protection_type-if-disk-is-reformatted-without-pi.patch [new file with mode: 0644]
queue-4.19/series
queue-4.19/xprtrdma-fix-completion-wait-during-device-removal.patch [new file with mode: 0644]

diff --git a/queue-4.19/platform-x86-asus-wmi-fix-keyboard-brightness-cannot-be-set-to-0.patch b/queue-4.19/platform-x86-asus-wmi-fix-keyboard-brightness-cannot-be-set-to-0.patch
new file mode 100644 (file)
index 0000000..d0aa356
--- /dev/null
@@ -0,0 +1,40 @@
+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);
+ }
diff --git a/queue-4.19/platform-x86-gpd-pocket-fan-use-default-values-when-wrong-modparams-are-given.patch b/queue-4.19/platform-x86-gpd-pocket-fan-use-default-values-when-wrong-modparams-are-given.patch
new file mode 100644 (file)
index 0000000..51cfd99
--- /dev/null
@@ -0,0 +1,89 @@
+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);
diff --git a/queue-4.19/scsi-enclosure-fix-stale-device-oops-with-hot-replug.patch b/queue-4.19/scsi-enclosure-fix-stale-device-oops-with-hot-replug.patch
new file mode 100644 (file)
index 0000000..5e6261b
--- /dev/null
@@ -0,0 +1,45 @@
+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;
diff --git a/queue-4.19/scsi-sd-clear-sdkp-protection_type-if-disk-is-reformatted-without-pi.patch b/queue-4.19/scsi-sd-clear-sdkp-protection_type-if-disk-is-reformatted-without-pi.patch
new file mode 100644 (file)
index 0000000..576a3d0
--- /dev/null
@@ -0,0 +1,42 @@
+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 */
index 91fa9cb0e961ead960b2d28a1f1195bf911baaf4..5e4f991d5673eb88ca953877c02fb38303434b4e 100644 (file)
@@ -34,3 +34,8 @@ drm-ttm-fix-incrementing-the-page-pointer-for-huge-pages.patch
 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
diff --git a/queue-4.19/xprtrdma-fix-completion-wait-during-device-removal.patch b/queue-4.19/xprtrdma-fix-completion-wait-during-device-removal.patch
new file mode 100644 (file)
index 0000000..306f145
--- /dev/null
@@ -0,0 +1,44 @@
+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);