--- /dev/null
+From 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Thu, 22 Oct 2015 10:56:40 -0400
+Subject: dm btree: fix leak of bufio-backed block in btree_split_beneath error path
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream.
+
+btree_split_beneath()'s error path had an outstanding FIXME that speaks
+directly to the potential for _not_ cleaning up a previously allocated
+bufio-backed block.
+
+Fix this by releasing the previously allocated bufio block using
+unlock_block().
+
+Reported-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Acked-by: Joe Thornber <thornber@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-btree.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/persistent-data/dm-btree.c
++++ b/drivers/md/persistent-data/dm-btree.c
+@@ -523,7 +523,7 @@ static int btree_split_beneath(struct sh
+
+ r = new_block(s->info, &right);
+ if (r < 0) {
+- /* FIXME: put left */
++ unlock_block(s->info, left);
+ return r;
+ }
+
--- /dev/null
+From 2871c69e025e8bc507651d5a9cf81a8a7da9d24b Mon Sep 17 00:00:00 2001
+From: Joe Thornber <ejt@redhat.com>
+Date: Wed, 21 Oct 2015 18:36:49 +0100
+Subject: dm btree remove: fix a bug when rebalancing nodes after removal
+
+From: Joe Thornber <ejt@redhat.com>
+
+commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b upstream.
+
+Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
+a complete fix for redistribute3().
+
+The redistribute3 function takes 3 btree nodes and shares out the entries
+evenly between them. If the three nodes in total contained
+(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
+rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
+the center.
+
+Fix this issue by being more careful about calculating the target number
+of entries for the left and right nodes.
+
+Unit tested in userspace using this program:
+https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c
+
+Signed-off-by: Joe Thornber <ejt@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-btree-remove.c | 17 +++++++++++------
+ 1 file changed, 11 insertions(+), 6 deletions(-)
+
+--- a/drivers/md/persistent-data/dm-btree-remove.c
++++ b/drivers/md/persistent-data/dm-btree-remove.c
+@@ -301,11 +301,16 @@ static void redistribute3(struct dm_btre
+ {
+ int s;
+ uint32_t max_entries = le32_to_cpu(left->header.max_entries);
+- unsigned target = (nr_left + nr_center + nr_right) / 3;
+- BUG_ON(target > max_entries);
++ unsigned total = nr_left + nr_center + nr_right;
++ unsigned target_right = total / 3;
++ unsigned remainder = (target_right * 3) != total;
++ unsigned target_left = target_right + remainder;
++
++ BUG_ON(target_left > max_entries);
++ BUG_ON(target_right > max_entries);
+
+ if (nr_left < nr_right) {
+- s = nr_left - target;
++ s = nr_left - target_left;
+
+ if (s < 0 && nr_center < -s) {
+ /* not enough in central node */
+@@ -316,10 +321,10 @@ static void redistribute3(struct dm_btre
+ } else
+ shift(left, center, s);
+
+- shift(center, right, target - nr_right);
++ shift(center, right, target_right - nr_right);
+
+ } else {
+- s = target - nr_right;
++ s = target_right - nr_right;
+ if (s > 0 && nr_center < s) {
+ /* not enough in central node */
+ shift(center, right, nr_center);
+@@ -329,7 +334,7 @@ static void redistribute3(struct dm_btre
+ } else
+ shift(center, right, s);
+
+- shift(left, center, nr_left - target);
++ shift(left, center, nr_left - target_left);
+ }
+
+ *key_ptr(parent, c->index) = center->keys[0];
--- /dev/null
+From 0729a04977d497cf66234fd7f900ddcec3ef1c52 Mon Sep 17 00:00:00 2001
+From: Hezi Shahmoon <hezi@marvell.com>
+Date: Tue, 20 Oct 2015 16:32:24 +0200
+Subject: i2c: mv64xxx: really allow I2C offloading
+
+From: Hezi Shahmoon <hezi@marvell.com>
+
+commit 0729a04977d497cf66234fd7f900ddcec3ef1c52 upstream.
+
+Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
+several problems") completely reworked the offload support, but left a
+debugging-related "return false" at the beginning of the
+mv64xxx_i2c_can_offload() function. This has the unfortunate consequence
+that offloading is in fact never used, which wasn't really the
+intention.
+
+This commit fixes that problem by removing the bogus "return false".
+
+Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems")
+Signed-off-by: Hezi Shahmoon <hezi@marvell.com>
+[Thomas: reworked commit log and title.]
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-mv64xxx.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-mv64xxx.c
++++ b/drivers/i2c/busses/i2c-mv64xxx.c
+@@ -669,8 +669,6 @@ mv64xxx_i2c_can_offload(struct mv64xxx_i
+ struct i2c_msg *msgs = drv_data->msgs;
+ int num = drv_data->num_msgs;
+
+- return false;
+-
+ if (!drv_data->offload_enabled)
+ return false;
+
--- /dev/null
+From 275d7d44d802ef271a42dc87ac091a495ba72fc5 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Thu, 20 Aug 2015 10:34:59 +0930
+Subject: module: Fix locking in symbol_put_addr()
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream.
+
+Poma (on the way to another bug) reported an assertion triggering:
+
+ [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
+ [<ffffffff81150822>] __module_address+0x32/0x150
+ [<ffffffff81150956>] __module_text_address+0x16/0x70
+ [<ffffffff81150f19>] symbol_put_addr+0x29/0x40
+ [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]
+
+Laura Abbott <labbott@redhat.com> produced a patch which lead us to
+inspect symbol_put_addr(). This function has a comment claiming it
+doesn't need to disable preemption around the module lookup
+because it holds a reference to the module it wants to find, which
+therefore cannot go away.
+
+This is wrong (and a false optimization too, preempt_disable() is really
+rather cheap, and I doubt any of this is on uber critical paths,
+otherwise it would've retained a pointer to the actual module anyway and
+avoided the second lookup).
+
+While its true that the module cannot go away while we hold a reference
+on it, the data structure we do the lookup in very much _CAN_ change
+while we do the lookup. Therefore fix the comment and add the
+required preempt_disable().
+
+Reported-by: poma <pomidorabelisima@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Fixes: a6e6abd575fc ("module: remove module_text_address()")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/module.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/kernel/module.c
++++ b/kernel/module.c
+@@ -906,11 +906,15 @@ void symbol_put_addr(void *addr)
+ if (core_kernel_text(a))
+ return;
+
+- /* module_text_address is safe here: we're supposed to have reference
+- * to module from symbol_get, so it can't go away. */
++ /*
++ * Even though we hold a reference on the module; we still need to
++ * disable preemption in order to safely traverse the data structure.
++ */
++ preempt_disable();
+ modaddr = __module_text_address(a);
+ BUG_ON(!modaddr);
+ module_put(modaddr);
++ preempt_enable();
+ }
+ EXPORT_SYMBOL_GPL(symbol_put_addr);
+
--- /dev/null
+From f967fc8f165fadb72166f2bd4785094b3ca21307 Mon Sep 17 00:00:00 2001
+From: Frederic Danis <frederic.danis@linux.intel.com>
+Date: Fri, 9 Oct 2015 17:14:56 +0200
+Subject: Revert "serial: 8250_dma: don't bother DMA with small transfers"
+
+From: Frederic Danis <frederic.danis@linux.intel.com>
+
+commit f967fc8f165fadb72166f2bd4785094b3ca21307 upstream.
+
+This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb.
+
+This commit prevents from sending "big" file using Bluetooth.
+When sending a lot of data quickly through the Bluetooth interface, and
+after a variable amount of data sent, transfer fails with error:
+ kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00
+
+Found on T100TA.
+
+After reverting this commit, send works fine for any file size.
+
+Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
+Fixes: 9119fba0cfed (serial: 8250_dma: don't bother DMA with small transfers)
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_dma.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_dma.c
++++ b/drivers/tty/serial/8250/8250_dma.c
+@@ -80,10 +80,6 @@ int serial8250_tx_dma(struct uart_8250_p
+ return 0;
+
+ dma->tx_size = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
+- if (dma->tx_size < p->port.fifosize) {
+- ret = -EINVAL;
+- goto err;
+- }
+
+ desc = dmaengine_prep_slave_single(dma->txchan,
+ dma->tx_addr + xmit->tail,
arm-8445-1-fix-vdsomunge-not-to-depend-on-glibc-specific-byteswap.h.patch
arm-8449-1-fix-bug-in-vdsomunge-swab32-macro.patch
revert-arm64-unwind-fix-pc-calculation.patch
+dm-btree-remove-fix-a-bug-when-rebalancing-nodes-after-removal.patch
+dm-btree-fix-leak-of-bufio-backed-block-in-btree_split_beneath-error-path.patch
+revert-serial-8250_dma-don-t-bother-dma-with-small-transfers.patch
+usb-qcserial-add-sierra-wireless-mc74xx-em74xx.patch
+i2c-mv64xxx-really-allow-i2c-offloading.patch
+xhci-handle-no-ping-response-error-properly.patch
+xhci-add-spurious-wakeup-quirk-for-lynxpoint-lp-controllers.patch
+xen-blkfront-check-for-null-drvdata-in-blkback_changed-xenbusstateclosing.patch
+module-fix-locking-in-symbol_put_addr.patch
--- /dev/null
+From f504ab1888026d15b5be8f9c262bf4ae9cacd177 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
+Date: Thu, 22 Oct 2015 14:24:24 +0200
+Subject: USB: qcserial: add Sierra Wireless MC74xx/EM74xx
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
+
+commit f504ab1888026d15b5be8f9c262bf4ae9cacd177 upstream.
+
+New device IDs shamelessly lifted from the vendor driver.
+
+Signed-off-by: Bjørn Mork <bjorn@mork.no>
+Acked-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/qcserial.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/serial/qcserial.c
++++ b/drivers/usb/serial/qcserial.c
+@@ -153,6 +153,8 @@ static const struct usb_device_id id_tab
+ {DEVICE_SWI(0x1199, 0x9056)}, /* Sierra Wireless Modem */
+ {DEVICE_SWI(0x1199, 0x9060)}, /* Sierra Wireless Modem */
+ {DEVICE_SWI(0x1199, 0x9061)}, /* Sierra Wireless Modem */
++ {DEVICE_SWI(0x1199, 0x9070)}, /* Sierra Wireless MC74xx/EM74xx */
++ {DEVICE_SWI(0x1199, 0x9071)}, /* Sierra Wireless MC74xx/EM74xx */
+ {DEVICE_SWI(0x413c, 0x81a2)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */
+ {DEVICE_SWI(0x413c, 0x81a3)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */
+ {DEVICE_SWI(0x413c, 0x81a4)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
--- /dev/null
+From a54c8f0f2d7df525ff997e2afe71866a1a013064 Mon Sep 17 00:00:00 2001
+From: Cathy Avery <cathy.avery@oracle.com>
+Date: Fri, 2 Oct 2015 09:35:01 -0400
+Subject: xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)
+
+From: Cathy Avery <cathy.avery@oracle.com>
+
+commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream.
+
+xen-blkfront will crash if the check to talk_to_blkback()
+in blkback_changed()(XenbusStateInitWait) returns an error.
+The driver data is freed and info is set to NULL. Later during
+the close process via talk_to_blkback's call to xenbus_dev_fatal()
+the null pointer is passed to and dereference in blkfront_closing.
+
+Signed-off-by: Cathy Avery <cathy.avery@oracle.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/xen-blkfront.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/block/xen-blkfront.c
++++ b/drivers/block/xen-blkfront.c
+@@ -1925,7 +1925,8 @@ static void blkback_changed(struct xenbu
+ break;
+ /* Missed the backend's Closing state -- fallthrough */
+ case XenbusStateClosing:
+- blkfront_closing(info);
++ if (info)
++ blkfront_closing(info);
+ break;
+ }
+ }
--- /dev/null
+From fd7cd061adcf5f7503515ba52b6a724642a839c8 Mon Sep 17 00:00:00 2001
+From: Laura Abbott <labbott@fedoraproject.org>
+Date: Mon, 12 Oct 2015 11:30:13 +0300
+Subject: xhci: Add spurious wakeup quirk for LynxPoint-LP controllers
+
+From: Laura Abbott <labbott@fedoraproject.org>
+
+commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.
+
+We received several reports of systems rebooting and powering on
+after an attempted shutdown. Testing showed that setting
+XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
+quirk allowed the system to shutdown as expected for LynxPoint-LP
+xHCI controllers. Set the quirk back.
+
+Note that the quirk was originally introduced for LynxPoint and
+LynxPoint-LP just for this same reason. See:
+
+commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")
+
+It was later limited to only concern HP machines as it caused
+regression on some machines, see both bug and commit:
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
+commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")
+
+Later it was discovered that the powering on after shutdown
+was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
+machine suffered from spontaneous resume from S3 (which should
+not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
+to fix this then removed the SPURIOUS_WAKEUP flag usage completely.
+
+commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")
+
+Current understanding is that LynxPoint-LP (Haswell ULT) machines
+need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
+plain Lynxpoint (Haswell) machines may _not_ have the quirk
+set otherwise they again will restart.
+
+Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
+Cc: Takashi Iwai <tiwai@suse.de>
+Cc: Oliver Neukum <oneukum@suse.com>
+[Added more history to commit message -Mathias]
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -135,6 +135,7 @@ static void xhci_pci_quirks(struct devic
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
++ xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+ }
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ (pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
--- /dev/null
+From 3b4739b8951d650becbcd855d7d6f18ac98a9a85 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Mon, 12 Oct 2015 11:30:12 +0300
+Subject: xhci: handle no ping response error properly
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream.
+
+If a host fails to wake up a isochronous SuperSpeed device from U1/U2
+in time for a isoch transfer it will generate a "No ping response error"
+Host will then move to the next transfer descriptor.
+
+Handle this case in the same way as missed service errors, tag the
+current TD as skipped and handle it on the next transfer event.
+
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-ring.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -2239,6 +2239,7 @@ static int handle_tx_event(struct xhci_h
+ u32 trb_comp_code;
+ int ret = 0;
+ int td_num = 0;
++ bool handling_skipped_tds = false;
+
+ slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
+ xdev = xhci->devs[slot_id];
+@@ -2372,6 +2373,10 @@ static int handle_tx_event(struct xhci_h
+ ep->skip = true;
+ xhci_dbg(xhci, "Miss service interval error, set skip flag\n");
+ goto cleanup;
++ case COMP_PING_ERR:
++ ep->skip = true;
++ xhci_dbg(xhci, "No Ping response error, Skip one Isoc TD\n");
++ goto cleanup;
+ default:
+ if (xhci_is_vendor_info_code(xhci, trb_comp_code)) {
+ status = 0;
+@@ -2508,13 +2513,18 @@ static int handle_tx_event(struct xhci_h
+ ep, &status);
+
+ cleanup:
++
++
++ handling_skipped_tds = ep->skip &&
++ trb_comp_code != COMP_MISSED_INT &&
++ trb_comp_code != COMP_PING_ERR;
++
+ /*
+- * Do not update event ring dequeue pointer if ep->skip is set.
+- * Will roll back to continue process missed tds.
++ * Do not update event ring dequeue pointer if we're in a loop
++ * processing missed tds.
+ */
+- if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
++ if (!handling_skipped_tds)
+ inc_deq(xhci, xhci->event_ring);
+- }
+
+ if (ret) {
+ urb = td->urb;
+@@ -2549,7 +2559,7 @@ cleanup:
+ * Process them as short transfer until reach the td pointed by
+ * the event.
+ */
+- } while (ep->skip && trb_comp_code != COMP_MISSED_INT);
++ } while (handling_skipped_tds);
+
+ return 0;
+ }