From: Greg Kroah-Hartman Date: Tue, 23 Jul 2019 09:50:44 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v5.2.3~56 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2d567a1264c61c4bd37e3375b3edb2813ab5ada2;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: arm64-tegra-update-jetson-tx1-gpu-regulator-timings.patch cifs-flush-before-set-info-if-we-have-writeable-handles.patch input-alps-don-t-handle-alps-cs19-trackpoint-only-device.patch input-alps-fix-a-mismatch-between-a-condition-check-and-its-comment.patch input-gtco-bounds-check-collection-indent-level.patch iwlwifi-pcie-don-t-service-an-interrupt-that-was-masked.patch regulator-s2mps11-fix-buck7-and-buck8-wrong-voltages.patch --- diff --git a/queue-4.9/arm64-tegra-update-jetson-tx1-gpu-regulator-timings.patch b/queue-4.9/arm64-tegra-update-jetson-tx1-gpu-regulator-timings.patch new file mode 100644 index 00000000000..f9fe288479a --- /dev/null +++ b/queue-4.9/arm64-tegra-update-jetson-tx1-gpu-regulator-timings.patch @@ -0,0 +1,38 @@ +From ece6031ece2dd64d63708cfe1088016cee5b10c0 Mon Sep 17 00:00:00 2001 +From: Jon Hunter +Date: Thu, 20 Jun 2019 09:17:01 +0100 +Subject: arm64: tegra: Update Jetson TX1 GPU regulator timings + +From: Jon Hunter + +commit ece6031ece2dd64d63708cfe1088016cee5b10c0 upstream. + +The GPU regulator enable ramp delay for Jetson TX1 is set to 1ms which +not sufficient because the enable ramp delay has been measured to be +greater than 1ms. Furthermore, the downstream kernels released by NVIDIA +for Jetson TX1 are using a enable ramp delay 2ms and a settling delay of +160us. Update the GPU regulator enable ramp delay for Jetson TX1 to be +2ms and add a settling delay of 160us. + +Cc: stable@vger.kernel.org +Signed-off-by: Jon Hunter +Fixes: 5e6b9a89afce ("arm64: tegra: Add VDD_GPU regulator to Jetson TX1") +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi ++++ b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi +@@ -306,7 +306,8 @@ + regulator-max-microvolt = <1320000>; + enable-gpios = <&pmic 6 GPIO_ACTIVE_HIGH>; + regulator-ramp-delay = <80>; +- regulator-enable-ramp-delay = <1000>; ++ regulator-enable-ramp-delay = <2000>; ++ regulator-settling-time-us = <160>; + }; + }; + }; diff --git a/queue-4.9/cifs-flush-before-set-info-if-we-have-writeable-handles.patch b/queue-4.9/cifs-flush-before-set-info-if-we-have-writeable-handles.patch new file mode 100644 index 00000000000..b170c859f8b --- /dev/null +++ b/queue-4.9/cifs-flush-before-set-info-if-we-have-writeable-handles.patch @@ -0,0 +1,61 @@ +From aa081859b10c5d8b19f5c525c78883a59d73c2b8 Mon Sep 17 00:00:00 2001 +From: Ronnie Sahlberg +Date: Fri, 19 Jul 2019 08:12:11 +1000 +Subject: cifs: flush before set-info if we have writeable handles + +From: Ronnie Sahlberg + +commit aa081859b10c5d8b19f5c525c78883a59d73c2b8 upstream. + +Servers can defer destaging any data and updating the mtime until close(). +This means that if we do a setinfo to modify the mtime while other handles +are open for write the server may overwrite our setinfo timestamps when +if flushes the file on close() of the writeable handle. + +To solve this we add an explicit flush when the mtime is about to +be updated. + +This fixes "cp -p" to preserve mtime when copying a file onto an SMB2 share. + +CC: Stable +Signed-off-by: Ronnie Sahlberg +Reviewed-by: Pavel Shilovsky +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/inode.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +--- a/fs/cifs/inode.c ++++ b/fs/cifs/inode.c +@@ -2335,6 +2335,8 @@ cifs_setattr_nounix(struct dentry *diren + struct inode *inode = d_inode(direntry); + struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb); + struct cifsInodeInfo *cifsInode = CIFS_I(inode); ++ struct cifsFileInfo *wfile; ++ struct cifs_tcon *tcon; + char *full_path = NULL; + int rc = -EACCES; + __u32 dosattr = 0; +@@ -2376,6 +2378,20 @@ cifs_setattr_nounix(struct dentry *diren + mapping_set_error(inode->i_mapping, rc); + rc = 0; + ++ if (attrs->ia_valid & ATTR_MTIME) { ++ rc = cifs_get_writable_file(cifsInode, false, &wfile); ++ if (!rc) { ++ tcon = tlink_tcon(wfile->tlink); ++ rc = tcon->ses->server->ops->flush(xid, tcon, &wfile->fid); ++ cifsFileInfo_put(wfile); ++ if (rc) ++ return rc; ++ } else if (rc != -EBADF) ++ return rc; ++ else ++ rc = 0; ++ } ++ + if (attrs->ia_valid & ATTR_SIZE) { + rc = cifs_set_file_size(inode, attrs, xid, full_path); + if (rc != 0) diff --git a/queue-4.9/input-alps-don-t-handle-alps-cs19-trackpoint-only-device.patch b/queue-4.9/input-alps-don-t-handle-alps-cs19-trackpoint-only-device.patch new file mode 100644 index 00000000000..60dc73691fc --- /dev/null +++ b/queue-4.9/input-alps-don-t-handle-alps-cs19-trackpoint-only-device.patch @@ -0,0 +1,101 @@ +From 7e4935ccc3236751e5fe4bd6846f86e46bb2e427 Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Mon, 15 Jul 2019 10:00:58 -0700 +Subject: Input: alps - don't handle ALPS cs19 trackpoint-only device +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hui Wang + +commit 7e4935ccc3236751e5fe4bd6846f86e46bb2e427 upstream. + +On a latest Lenovo laptop, the trackpoint and 3 buttons below it +don't work at all, when we move the trackpoint or press those 3 +buttons, the kernel will print out: +"Rejected trackstick packet from non DualPoint device" + +This device is identified as an alps touchpad but the packet has +trackpoint format, so the alps.c drops the packet and prints out +the message above. + +According to XiaoXiao's explanation, this device is named cs19 and +is trackpoint-only device, its firmware is only for trackpoint, it +is independent of touchpad and is a device completely different from +DualPoint ones. + +To drive this device with mininal changes to the existing driver, we +just let the alps driver not handle this device, then the trackpoint.c +will be the driver of this device if the trackpoint driver is enabled. +(if not, this device will fallback to a bare PS/2 device) + +With the trackpoint.c, this trackpoint and 3 buttons all work well, +they have all features that the trackpoint should have, like +scrolling-screen, drag-and-drop and frame-selection. + +Signed-off-by: XiaoXiao Liu +Signed-off-by: Hui Wang +Reviewed-by: Pali Rohár +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/alps.c | 32 ++++++++++++++++++++++++++++++++ + 1 file changed, 32 insertions(+) + +--- a/drivers/input/mouse/alps.c ++++ b/drivers/input/mouse/alps.c +@@ -24,6 +24,7 @@ + + #include "psmouse.h" + #include "alps.h" ++#include "trackpoint.h" + + /* + * Definitions for ALPS version 3 and 4 command mode protocol +@@ -2858,6 +2859,23 @@ static const struct alps_protocol_info * + return NULL; + } + ++static bool alps_is_cs19_trackpoint(struct psmouse *psmouse) ++{ ++ u8 param[2] = { 0 }; ++ ++ if (ps2_command(&psmouse->ps2dev, ++ param, MAKE_PS2_CMD(0, 2, TP_READ_ID))) ++ return false; ++ ++ /* ++ * param[0] contains the trackpoint device variant_id while ++ * param[1] contains the firmware_id. So far all alps ++ * trackpoint-only devices have their variant_ids equal ++ * TP_VARIANT_ALPS and their firmware_ids are in 0x20~0x2f range. ++ */ ++ return param[0] == TP_VARIANT_ALPS && (param[1] & 0x20); ++} ++ + static int alps_identify(struct psmouse *psmouse, struct alps_data *priv) + { + const struct alps_protocol_info *protocol; +@@ -3150,6 +3168,20 @@ int alps_detect(struct psmouse *psmouse, + return error; + + /* ++ * ALPS cs19 is a trackpoint-only device, and uses different ++ * protocol than DualPoint ones, so we return -EINVAL here and let ++ * trackpoint.c drive this device. If the trackpoint driver is not ++ * enabled, the device will fall back to a bare PS/2 mouse. ++ * If ps2_command() fails here, we depend on the immediately ++ * followed psmouse_reset() to reset the device to normal state. ++ */ ++ if (alps_is_cs19_trackpoint(psmouse)) { ++ psmouse_dbg(psmouse, ++ "ALPS CS19 trackpoint-only device detected, ignoring\n"); ++ return -EINVAL; ++ } ++ ++ /* + * Reset the device to make sure it is fully operational: + * on some laptops, like certain Dell Latitudes, we may + * fail to properly detect presence of trackstick if device diff --git a/queue-4.9/input-alps-fix-a-mismatch-between-a-condition-check-and-its-comment.patch b/queue-4.9/input-alps-fix-a-mismatch-between-a-condition-check-and-its-comment.patch new file mode 100644 index 00000000000..88c823d7742 --- /dev/null +++ b/queue-4.9/input-alps-fix-a-mismatch-between-a-condition-check-and-its-comment.patch @@ -0,0 +1,38 @@ +From 771a081e44a9baa1991ef011cc453ef425591740 Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Fri, 19 Jul 2019 12:38:58 +0300 +Subject: Input: alps - fix a mismatch between a condition check and its comment + +From: Hui Wang + +commit 771a081e44a9baa1991ef011cc453ef425591740 upstream. + +In the function alps_is_cs19_trackpoint(), we check if the param[1] is +in the 0x20~0x2f range, but the code we wrote for this checking is not +correct: +(param[1] & 0x20) does not mean param[1] is in the range of 0x20~0x2f, +it also means the param[1] is in the range of 0x30~0x3f, 0x60~0x6f... + +Now fix it with a new condition checking ((param[1] & 0xf0) == 0x20). + +Fixes: 7e4935ccc323 ("Input: alps - don't handle ALPS cs19 trackpoint-only device") +Cc: stable@vger.kernel.org +Signed-off-by: Hui Wang +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/alps.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/input/mouse/alps.c ++++ b/drivers/input/mouse/alps.c +@@ -2873,7 +2873,7 @@ static bool alps_is_cs19_trackpoint(stru + * trackpoint-only devices have their variant_ids equal + * TP_VARIANT_ALPS and their firmware_ids are in 0x20~0x2f range. + */ +- return param[0] == TP_VARIANT_ALPS && (param[1] & 0x20); ++ return param[0] == TP_VARIANT_ALPS && ((param[1] & 0xf0) == 0x20); + } + + static int alps_identify(struct psmouse *psmouse, struct alps_data *priv) diff --git a/queue-4.9/input-gtco-bounds-check-collection-indent-level.patch b/queue-4.9/input-gtco-bounds-check-collection-indent-level.patch new file mode 100644 index 00000000000..29900e91a18 --- /dev/null +++ b/queue-4.9/input-gtco-bounds-check-collection-indent-level.patch @@ -0,0 +1,79 @@ +From 2a017fd82c5402b3c8df5e3d6e5165d9e6147dc1 Mon Sep 17 00:00:00 2001 +From: Grant Hernandez +Date: Sat, 13 Jul 2019 01:00:12 -0700 +Subject: Input: gtco - bounds check collection indent level + +From: Grant Hernandez + +commit 2a017fd82c5402b3c8df5e3d6e5165d9e6147dc1 upstream. + +The GTCO tablet input driver configures itself from an HID report sent +via USB during the initial enumeration process. Some debugging messages +are generated during the parsing. A debugging message indentation +counter is not bounds checked, leading to the ability for a specially +crafted HID report to cause '-' and null bytes be written past the end +of the indentation array. As long as the kernel has CONFIG_DYNAMIC_DEBUG +enabled, this code will not be optimized out. This was discovered +during code review after a previous syzkaller bug was found in this +driver. + +Signed-off-by: Grant Hernandez +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/tablet/gtco.c | 20 +++++++++++++++++--- + 1 file changed, 17 insertions(+), 3 deletions(-) + +--- a/drivers/input/tablet/gtco.c ++++ b/drivers/input/tablet/gtco.c +@@ -78,6 +78,7 @@ Scott Hill shill@gtcocalcomp.com + + /* Max size of a single report */ + #define REPORT_MAX_SIZE 10 ++#define MAX_COLLECTION_LEVELS 10 + + + /* Bitmask whether pen is in range */ +@@ -223,8 +224,7 @@ static void parse_hid_report_descriptor( + char maintype = 'x'; + char globtype[12]; + int indent = 0; +- char indentstr[10] = ""; +- ++ char indentstr[MAX_COLLECTION_LEVELS + 1] = { 0 }; + + dev_dbg(ddev, "======>>>>>>PARSE<<<<<<======\n"); + +@@ -350,6 +350,13 @@ static void parse_hid_report_descriptor( + case TAG_MAIN_COL_START: + maintype = 'S'; + ++ if (indent == MAX_COLLECTION_LEVELS) { ++ dev_err(ddev, "Collection level %d would exceed limit of %d\n", ++ indent + 1, ++ MAX_COLLECTION_LEVELS); ++ break; ++ } ++ + if (data == 0) { + dev_dbg(ddev, "======>>>>>> Physical\n"); + strcpy(globtype, "Physical"); +@@ -369,8 +376,15 @@ static void parse_hid_report_descriptor( + break; + + case TAG_MAIN_COL_END: +- dev_dbg(ddev, "<<<<<<======\n"); + maintype = 'E'; ++ ++ if (indent == 0) { ++ dev_err(ddev, "Collection level already at zero\n"); ++ break; ++ } ++ ++ dev_dbg(ddev, "<<<<<<======\n"); ++ + indent--; + for (x = 0; x < indent; x++) + indentstr[x] = '-'; diff --git a/queue-4.9/iwlwifi-pcie-don-t-service-an-interrupt-that-was-masked.patch b/queue-4.9/iwlwifi-pcie-don-t-service-an-interrupt-that-was-masked.patch new file mode 100644 index 00000000000..bf7749c3e04 --- /dev/null +++ b/queue-4.9/iwlwifi-pcie-don-t-service-an-interrupt-that-was-masked.patch @@ -0,0 +1,72 @@ +From 3b57a10ca14c619707398dc58fe5ece18c95b20b Mon Sep 17 00:00:00 2001 +From: Emmanuel Grumbach +Date: Tue, 21 May 2019 15:10:38 +0300 +Subject: iwlwifi: pcie: don't service an interrupt that was masked + +From: Emmanuel Grumbach + +commit 3b57a10ca14c619707398dc58fe5ece18c95b20b upstream. + +Sometimes the register status can include interrupts that +were masked. We can, for example, get the RF-Kill bit set +in the interrupt status register although this interrupt +was masked. Then if we get the ALIVE interrupt (for example) +that was not masked, we need to *not* service the RF-Kill +interrupt. +Fix this in the MSI-X interrupt handler. + +Cc: stable@vger.kernel.org +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Luca Coelho +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 27 +++++++++++++++++++++------ + 1 file changed, 21 insertions(+), 6 deletions(-) + +--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c +@@ -1901,10 +1901,18 @@ irqreturn_t iwl_pcie_irq_msix_handler(in + return IRQ_NONE; + } + +- if (iwl_have_debug_level(IWL_DL_ISR)) +- IWL_DEBUG_ISR(trans, "ISR inta_fh 0x%08x, enabled 0x%08x\n", +- inta_fh, ++ if (iwl_have_debug_level(IWL_DL_ISR)) { ++ IWL_DEBUG_ISR(trans, ++ "ISR inta_fh 0x%08x, enabled (sw) 0x%08x (hw) 0x%08x\n", ++ inta_fh, trans_pcie->fh_mask, + iwl_read32(trans, CSR_MSIX_FH_INT_MASK_AD)); ++ if (inta_fh & ~trans_pcie->fh_mask) ++ IWL_DEBUG_ISR(trans, ++ "We got a masked interrupt (0x%08x)\n", ++ inta_fh & ~trans_pcie->fh_mask); ++ } ++ ++ inta_fh &= trans_pcie->fh_mask; + + if ((trans_pcie->shared_vec_mask & IWL_SHARED_IRQ_NON_RX) && + inta_fh & MSIX_FH_INT_CAUSES_Q0) { +@@ -1943,11 +1951,18 @@ irqreturn_t iwl_pcie_irq_msix_handler(in + } + + /* After checking FH register check HW register */ +- if (iwl_have_debug_level(IWL_DL_ISR)) ++ if (iwl_have_debug_level(IWL_DL_ISR)) { + IWL_DEBUG_ISR(trans, +- "ISR inta_hw 0x%08x, enabled 0x%08x\n", +- inta_hw, ++ "ISR inta_hw 0x%08x, enabled (sw) 0x%08x (hw) 0x%08x\n", ++ inta_hw, trans_pcie->hw_mask, + iwl_read32(trans, CSR_MSIX_HW_INT_MASK_AD)); ++ if (inta_hw & ~trans_pcie->hw_mask) ++ IWL_DEBUG_ISR(trans, ++ "We got a masked interrupt 0x%08x\n", ++ inta_hw & ~trans_pcie->hw_mask); ++ } ++ ++ inta_hw &= trans_pcie->hw_mask; + + /* Alive notification via Rx interrupt will do the real work */ + if (inta_hw & MSIX_HW_INT_CAUSES_REG_ALIVE) { diff --git a/queue-4.9/regulator-s2mps11-fix-buck7-and-buck8-wrong-voltages.patch b/queue-4.9/regulator-s2mps11-fix-buck7-and-buck8-wrong-voltages.patch new file mode 100644 index 00000000000..ae0bd6b730e --- /dev/null +++ b/queue-4.9/regulator-s2mps11-fix-buck7-and-buck8-wrong-voltages.patch @@ -0,0 +1,42 @@ +From 16da0eb5ab6ef2dd1d33431199126e63db9997cc Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Sat, 29 Jun 2019 13:44:45 +0200 +Subject: regulator: s2mps11: Fix buck7 and buck8 wrong voltages + +From: Krzysztof Kozlowski + +commit 16da0eb5ab6ef2dd1d33431199126e63db9997cc upstream. + +On S2MPS11 device, the buck7 and buck8 regulator voltages start at 750 +mV, not 600 mV. Using wrong minimal value caused shifting of these +regulator values by 150 mV (e.g. buck7 usually configured to v1.35 V was +reported as 1.2 V). + +On most of the boards these regulators are left in default state so this +was only affecting reported voltage. However if any driver wanted to +change them, then effectively it would set voltage 150 mV higher than +intended. + +Cc: +Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver") +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/regulator/s2mps11.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/regulator/s2mps11.c ++++ b/drivers/regulator/s2mps11.c +@@ -386,8 +386,8 @@ static const struct regulator_desc s2mps + regulator_desc_s2mps11_buck1_4(4), + regulator_desc_s2mps11_buck5, + regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV), +- regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV), +- regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV), ++ regulator_desc_s2mps11_buck67810(7, MIN_750_MV, STEP_12_5_MV), ++ regulator_desc_s2mps11_buck67810(8, MIN_750_MV, STEP_12_5_MV), + regulator_desc_s2mps11_buck9, + regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV), + }; diff --git a/queue-4.9/series b/queue-4.9/series index 4b72ca491ab..926cf939b3e 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -85,3 +85,10 @@ crypto-arm64-sha1-ce-correct-digest-for-empty-data-in-finup.patch crypto-arm64-sha2-ce-correct-digest-for-empty-data-in-finup.patch crypto-chacha20poly1305-fix-atomic-sleep-when-using-async-algorithm.patch crypto-crypto4xx-fix-a-potential-double-free-in-ppc4xx_trng_probe.patch +cifs-flush-before-set-info-if-we-have-writeable-handles.patch +input-gtco-bounds-check-collection-indent-level.patch +input-alps-don-t-handle-alps-cs19-trackpoint-only-device.patch +input-alps-fix-a-mismatch-between-a-condition-check-and-its-comment.patch +regulator-s2mps11-fix-buck7-and-buck8-wrong-voltages.patch +arm64-tegra-update-jetson-tx1-gpu-regulator-timings.patch +iwlwifi-pcie-don-t-service-an-interrupt-that-was-masked.patch