From: Greg Kroah-Hartman Date: Mon, 24 Apr 2017 08:01:33 +0000 (+0100) Subject: 3.18-stable patches X-Git-Tag: v4.4.64~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1dc83e4e4dc9a0d5eb00647e657074b335bf9d50;p=thirdparty%2Fkernel%2Fstable-queue.git 3.18-stable patches added patches: acpi-power-avoid-maybe-uninitialized-warning.patch input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch ubi-upd-always-flush-after-prepared-for-an-update.patch --- diff --git a/queue-3.18/acpi-power-avoid-maybe-uninitialized-warning.patch b/queue-3.18/acpi-power-avoid-maybe-uninitialized-warning.patch new file mode 100644 index 00000000000..b0a05eeda16 --- /dev/null +++ b/queue-3.18/acpi-power-avoid-maybe-uninitialized-warning.patch @@ -0,0 +1,45 @@ +From fe8c470ab87d90e4b5115902dd94eced7e3305c3 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Wed, 19 Apr 2017 19:47:04 +0200 +Subject: ACPI / power: Avoid maybe-uninitialized warning + +From: Arnd Bergmann + +commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream. + +gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state() +is enterered at least once, so it assumes that cur_state might not get +initialized: + +drivers/acpi/power.c: In function 'acpi_power_get_inferred_state': +drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized] + +This sets the variable to zero at the start of the loop, to ensure that +there is well-defined behavior even for an empty list. This gets rid of +the warning. + +The warning first showed up when the -Os flag got removed in a bug fix +patch in linux-4.11-rc5. + +I would suggest merging this addon patch on top of that bug fix to avoid +introducing a new warning in the stable kernels. + +Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing) +Signed-off-by: Arnd Bergmann +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/power.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/acpi/power.c ++++ b/drivers/acpi/power.c +@@ -201,6 +201,7 @@ static int acpi_power_get_list_state(str + return -EINVAL; + + /* The state of the list is 'on' IFF all resources are 'on'. */ ++ cur_state = 0; + list_for_each_entry(entry, list, node) { + struct acpi_power_resource *resource = entry->resource; + acpi_handle handle = resource->device.handle; diff --git a/queue-3.18/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch b/queue-3.18/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch new file mode 100644 index 00000000000..512d3af7517 --- /dev/null +++ b/queue-3.18/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch @@ -0,0 +1,49 @@ +From 704de489e0e3640a2ee2d0daf173e9f7375582ba Mon Sep 17 00:00:00 2001 +From: Thorsten Leemhuis +Date: Tue, 18 Apr 2017 11:14:28 -0700 +Subject: Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled + +From: Thorsten Leemhuis + +commit 704de489e0e3640a2ee2d0daf173e9f7375582ba upstream. + +Temporary got a Lifebook E547 into my hands and noticed the touchpad +only works after running: + + echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled + +Add it to the list of machines that need this workaround. + +Signed-off-by: Thorsten Leemhuis +Reviewed-by: Ulrik De Bie +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/elantech.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/input/mouse/elantech.c ++++ b/drivers/input/mouse/elantech.c +@@ -1115,6 +1115,7 @@ static int elantech_get_resolution_v4(st + * Asus UX32VD 0x361f02 00, 15, 0e clickpad + * Avatar AVIU-145A2 0x361f00 ? clickpad + * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons ++ * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons + * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons + * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**) + * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons +@@ -1496,6 +1497,13 @@ static const struct dmi_system_id elante + }, + }, + { ++ /* Fujitsu LIFEBOOK E547 does not work with crc_enabled == 0 */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E547"), ++ }, ++ }, ++ { + /* Fujitsu LIFEBOOK E554 does not work with crc_enabled == 0 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), diff --git a/queue-3.18/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch b/queue-3.18/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch new file mode 100644 index 00000000000..1f7865fb428 --- /dev/null +++ b/queue-3.18/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch @@ -0,0 +1,40 @@ +From 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 Mon Sep 17 00:00:00 2001 +From: Haibo Chen +Date: Wed, 19 Apr 2017 10:53:51 +0800 +Subject: mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card + +From: Haibo Chen + +commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream. + +Currently for DDR50 card, it need tuning in default. We meet tuning fail +issue for DDR50 card and some data CRC error when DDR50 sd card works. + +This is because the default pad I/O drive strength can't make sure DDR50 +card work stable. So increase the pad I/O drive strength for DDR50 card, +and use pins_100mhz. + +This fixes DDR50 card support for IMX since DDR50 tuning was enabled from +commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50") + +Tested-and-reported-by: Tim Harvey +Signed-off-by: Haibo Chen +Acked-by: Dong Aisheng +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-esdhc-imx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mmc/host/sdhci-esdhc-imx.c ++++ b/drivers/mmc/host/sdhci-esdhc-imx.c +@@ -824,6 +824,7 @@ static int esdhc_change_pinstate(struct + + switch (uhs) { + case MMC_TIMING_UHS_SDR50: ++ case MMC_TIMING_UHS_DDR50: + pinctrl = imx_data->pins_100mhz; + break; + case MMC_TIMING_UHS_SDR104: diff --git a/queue-3.18/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch b/queue-3.18/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch new file mode 100644 index 00000000000..eda9c56d52f --- /dev/null +++ b/queue-3.18/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch @@ -0,0 +1,64 @@ +From 9e1ba4f27f018742a1aa95d11e35106feba08ec1 Mon Sep 17 00:00:00 2001 +From: Ravi Bangoria +Date: Tue, 11 Apr 2017 10:38:13 +0530 +Subject: powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction + +From: Ravi Bangoria + +commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 upstream. + +If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel +OOPS: + + Bad kernel stack pointer cd93c840 at c000000000009868 + Oops: Bad kernel stack pointer, sig: 6 [#1] + ... + GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840 + ... + NIP [c000000000009868] resume_kernel+0x2c/0x58 + LR [c000000000006208] program_check_common+0x108/0x180 + +On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does +not emulate actual store in emulate_step() because it may corrupt the exception +frame. So the kernel does the actual store operation in exception return code +i.e. resume_kernel(). + +resume_kernel() loads the saved stack pointer from memory using lwz, which only +loads the low 32-bits of the address, causing the kernel crash. + +Fix this by loading the 64-bit value instead. + +Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()") +Signed-off-by: Ravi Bangoria +Reviewed-by: Naveen N. Rao +Reviewed-by: Ananth N Mavinakayanahalli +[mpe: Change log massage, add stable tag] +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/entry_64.S | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/powerpc/kernel/entry_64.S ++++ b/arch/powerpc/kernel/entry_64.S +@@ -677,7 +677,7 @@ resume_kernel: + + addi r8,r1,INT_FRAME_SIZE /* Get the kprobed function entry */ + +- lwz r3,GPR1(r1) ++ ld r3,GPR1(r1) + subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception frame */ + mr r4,r1 /* src: current exception frame */ + mr r1,r3 /* Reroute the trampoline frame to r1 */ +@@ -691,8 +691,8 @@ resume_kernel: + addi r6,r6,8 + bdnz 2b + +- /* Do real store operation to complete stwu */ +- lwz r5,GPR1(r1) ++ /* Do real store operation to complete stdu */ ++ ld r5,GPR1(r1) + std r8,0(r5) + + /* Clear _TIF_EMULATE_STACK_STORE flag */ diff --git a/queue-3.18/series b/queue-3.18/series index f0a511378e1..096d5947013 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -7,3 +7,8 @@ cifs-do-not-send-echoes-before-negotiate-is-complete.patch cifs-remove-bad_network_name-flag.patch s390-mm-fix-cmma-vs-ksm-vs-others.patch +input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch +acpi-power-avoid-maybe-uninitialized-warning.patch +mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch +ubi-upd-always-flush-after-prepared-for-an-update.patch +powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch diff --git a/queue-3.18/ubi-upd-always-flush-after-prepared-for-an-update.patch b/queue-3.18/ubi-upd-always-flush-after-prepared-for-an-update.patch new file mode 100644 index 00000000000..a2b306c0fbc --- /dev/null +++ b/queue-3.18/ubi-upd-always-flush-after-prepared-for-an-update.patch @@ -0,0 +1,64 @@ +From 9cd9a21ce070be8a918ffd3381468315a7a76ba6 Mon Sep 17 00:00:00 2001 +From: Sebastian Siewior +Date: Wed, 22 Feb 2017 17:15:21 +0100 +Subject: ubi/upd: Always flush after prepared for an update + +From: Sebastian Siewior + +commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream. + +In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I +managed to trigger and fix a similar bug. Now here is another version of +which I assumed it wouldn't matter back then but it turns out UBI has a +check for it and will error out like this: + +|ubi0 warning: validate_vid_hdr: inconsistent used_ebs +|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592 + +All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a +powercut in the middle of the operation. +ubi_start_update() sets the update-marker and puts all EBs on the erase +list. After that userland can proceed to write new data while the old EB +aren't erased completely. A powercut at this point is usually not that +much of a tragedy. UBI won't give read access to the static volume +because it has the update marker. It will most likely set the corrupted +flag because it misses some EBs. +So we are all good. Unless the size of the image that has been written +differs from the old image in the magnitude of at least one EB. In that +case UBI will find two different values for `used_ebs' and refuse to +attach the image with the error message mentioned above. + +So in order not to get in the situation, the patch will ensure that we +wait until everything is removed before it tries to write any data. +The alternative would be to detect such a case and remove all EBs at the +attached time after we processed the volume-table and see the +update-marker set. The patch looks bigger and I doubt it is worth it +since usually the write() will wait from time to time for a new EB since +usually there not that many spare EB that can be used. + +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/upd.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/mtd/ubi/upd.c ++++ b/drivers/mtd/ubi/upd.c +@@ -148,11 +148,11 @@ int ubi_start_update(struct ubi_device * + return err; + } + +- if (bytes == 0) { +- err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL); +- if (err) +- return err; ++ err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL); ++ if (err) ++ return err; + ++ if (bytes == 0) { + err = clear_update_marker(ubi, vol, 0); + if (err) + return err;