--- /dev/null
+From fe8c470ab87d90e4b5115902dd94eced7e3305c3 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Wed, 19 Apr 2017 19:47:04 +0200
+Subject: ACPI / power: Avoid maybe-uninitialized warning
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <arnd@arndb.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/power.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/acpi/power.c
++++ b/drivers/acpi/power.c
+@@ -200,6 +200,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;
--- /dev/null
+From 704de489e0e3640a2ee2d0daf173e9f7375582ba Mon Sep 17 00:00:00 2001
+From: Thorsten Leemhuis <linux@leemhuis.info>
+Date: Tue, 18 Apr 2017 11:14:28 -0700
+Subject: Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled
+
+From: Thorsten Leemhuis <linux@leemhuis.info>
+
+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 <linux@leemhuis.info>
+Reviewed-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elantech.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -1122,6 +1122,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 T725 0x470f01 05, 12, 09 2 hw buttons
+ * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**)
+@@ -1528,6 +1529,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"),
--- /dev/null
+From 3018e947d7fd536d57e2b550c33e456d921fff8c Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Thu, 20 Apr 2017 21:32:16 +0200
+Subject: mac80211: reject ToDS broadcast data frames
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream.
+
+AP/AP_VLAN modes don't accept any real 802.11 multicast data
+frames, but since they do need to accept broadcast management
+frames the same is currently permitted for data frames. This
+opens a security problem because such frames would be decrypted
+with the GTK, and could even contain unicast L3 frames.
+
+Since the spec says that ToDS frames must always have the BSSID
+as the RA (addr1), reject any other data frames.
+
+The problem was originally reported in "Predicting, Decrypting,
+and Abusing WPA2/802.11 Group Keys" at usenix
+https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef
+and brought to my attention by Jouni.
+
+Reported-by: Jouni Malinen <j@w1.fi>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+--
+
+---
+ net/mac80211/rx.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+--- a/net/mac80211/rx.c
++++ b/net/mac80211/rx.c
+@@ -3396,6 +3396,27 @@ static bool ieee80211_accept_frame(struc
+ !ether_addr_equal(bssid, hdr->addr1))
+ return false;
+ }
++
++ /*
++ * 802.11-2016 Table 9-26 says that for data frames, A1 must be
++ * the BSSID - we've checked that already but may have accepted
++ * the wildcard (ff:ff:ff:ff:ff:ff).
++ *
++ * It also says:
++ * The BSSID of the Data frame is determined as follows:
++ * a) If the STA is contained within an AP or is associated
++ * with an AP, the BSSID is the address currently in use
++ * by the STA contained in the AP.
++ *
++ * So we should not accept data frames with an address that's
++ * multicast.
++ *
++ * Accepting it also opens a security problem because stations
++ * could encrypt it with the GTK and inject traffic that way.
++ */
++ if (ieee80211_is_data(hdr->frame_control) && multicast)
++ return false;
++
+ return true;
+ case NL80211_IFTYPE_WDS:
+ if (bssid || !ieee80211_is_data(hdr->frame_control))
--- /dev/null
+From 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 Mon Sep 17 00:00:00 2001
+From: Haibo Chen <haibo.chen@nxp.com>
+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 <haibo.chen@nxp.com>
+
+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 <tharvey@gateworks.com>
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -804,6 +804,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:
--- /dev/null
+From 9e1ba4f27f018742a1aa95d11e35106feba08ec1 Mon Sep 17 00:00:00 2001
+From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
+Date: Tue, 11 Apr 2017 10:38:13 +0530
+Subject: powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction
+
+From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
+
+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 <ravi.bangoria@linux.vnet.ibm.com>
+Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
+[mpe: Change log massage, add stable tag]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -716,7 +716,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 */
+@@ -730,8 +730,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 */
drivers-hv-get-rid-of-timeout-in-vmbus_open.patch
drivers-hv-vmbus-reduce-the-delay-between-retries-in-vmbus_post_msg.patch
vsock-detach-qp-check-should-filter-out-non-matching-qps.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
+mac80211-reject-tods-broadcast-data-frames.patch
+ubi-upd-always-flush-after-prepared-for-an-update.patch
+powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch
--- /dev/null
+From 9cd9a21ce070be8a918ffd3381468315a7a76ba6 Mon Sep 17 00:00:00 2001
+From: Sebastian Siewior <bigeasy@linutronix.de>
+Date: Wed, 22 Feb 2017 17:15:21 +0100
+Subject: ubi/upd: Always flush after prepared for an update
+
+From: Sebastian Siewior <bigeasy@linutronix.de>
+
+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 <bigeasy@linutronix.de>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
