--- /dev/null
+arm-omap2-hwmod-fix-updating-of-sysconfig-register.patch
+assoc_array-don-t-call-compare_object-on-a-node.patch
+usb-host-xhci-plat-fix-cannot-work-if-r-car-gen2-3-run-on-above-4gb-phys.patch
+usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch
+usb-hcd-out-of-bounds-access-in-for_each_companion.patch
--- /dev/null
+block-partition-initialize-percpuref-before-sending-out-kobj_add.patch
+block-loop-fix-filesystem-corruption-in-case-of-aio-dio.patch
+x86-mce-avoid-using-object-after-free-in-genpool.patch
+kvm-x86-do-not-leak-guest-xcr0-into-host-interrupt-handlers.patch
+kvm-arm-arm64-handle-forward-time-correction-gracefully.patch
+arm-dts-am43x-epos-fix-clk-parent-for-synctimer.patch
+arm-mvebu-correct-unit-address-for-linksys.patch
+arm-omap2-fix-up-interconnect-barrier-initialization-for-dra7.patch
+arm-omap2-hwmod-fix-updating-of-sysconfig-register.patch
+assoc_array-don-t-call-compare_object-on-a-node.patch
+usb-xhci-applying-xhci_pme_stuck_quirk-to-intel-bxt-b0-host.patch
+xhci-resume-usb-3-roothub-first.patch
+usb-host-xhci-plat-fix-cannot-work-if-r-car-gen2-3-run-on-above-4gb-phys.patch
+usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch
+xhci-fix-10-second-timeout-on-removal-of-pci-hotpluggable-xhci-controllers.patch
+usb-hcd-out-of-bounds-access-in-for_each_companion.patch
+usb-gadget-f_fs-fix-use-after-free.patch
--- /dev/null
+From cfe1580a6415bc37fd62d79eb8102a618f7650b2 Mon Sep 17 00:00:00 2001
+From: Lokesh Vutla <lokeshvutla@ti.com>
+Date: Tue, 8 Mar 2016 12:24:35 +0530
+Subject: ARM: dts: AM43x-epos: Fix clk parent for synctimer
+
+From: Lokesh Vutla <lokeshvutla@ti.com>
+
+commit cfe1580a6415bc37fd62d79eb8102a618f7650b2 upstream.
+
+commit 55ee7017ee31 ("arm: omap2: board-generic: use omap4_local_timer_init
+for AM437x") makes synctimer32k as the clocksource on AM43xx. By default
+the synctimer32k is clocked by 32K RTC OSC on AM43xx. But this 32K RTC OSC
+is not available on epos boards which makes it fail to boot.
+
+Synctimer32k can also be clocked by a peripheral PLL, so making this as
+clock parent for synctimer3k on epos boards.
+
+Fixes: 55ee7017ee31 ("arm: omap2: board-generic: use omap4_local_timer_init for AM437x")
+Reported-by: Nishanth Menon <nm@ti.com>
+Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/am43x-epos-evm.dts | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/arm/boot/dts/am43x-epos-evm.dts
++++ b/arch/arm/boot/dts/am43x-epos-evm.dts
+@@ -792,3 +792,8 @@
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+ };
++
++&synctimer_32kclk {
++ assigned-clocks = <&mux_synctimer32k_ck>;
++ assigned-clock-parents = <&clkdiv32k_ick>;
++};
--- /dev/null
+From d41676ddddef27224a398609d874055866694cfa Mon Sep 17 00:00:00 2001
+From: Tero Kristo <t-kristo@ti.com>
+Date: Mon, 14 Mar 2016 11:01:50 +0200
+Subject: ARM: dts: am43xx: fix edma memcpy channel allocation
+
+From: Tero Kristo <t-kristo@ti.com>
+
+commit d41676ddddef27224a398609d874055866694cfa upstream.
+
+EDMA was allocating DMA channels 32 and 33 for memcpy usage, out of which
+channel 33 is actually used by DES crypto engine. This bad allocation of
+the channel causes a crash in the DES crypto engine, as the channel
+gets configured for memcpy usage instead of hardware <-> memory DMA.
+
+Fixed by allocating DMA channels 58 and 59 for memcpy usage (I2C0 RX/TX),
+which are not used by anybody.
+
+Fixes: cce1ee000187 ("ARM: DTS: am437x: Use the new DT bindings for
+the eDMA3")
+Signed-off-by: Tero Kristo <t-kristo@ti.com>
+Suggested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/am4372.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/am4372.dtsi
++++ b/arch/arm/boot/dts/am4372.dtsi
+@@ -207,7 +207,7 @@
+ ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
+ <&edma_tptc2 0>;
+
+- ti,edma-memcpy-channels = <32 33>;
++ ti,edma-memcpy-channels = <58 59>;
+ };
+
+ edma_tptc0: tptc@49800000 {
--- /dev/null
+From 199831c77c50e6913e893b6bc268ba9f4a9a2bf8 Mon Sep 17 00:00:00 2001
+From: Patrick Uiterwijk <patrick@puiterwijk.org>
+Date: Tue, 29 Mar 2016 16:57:40 +0000
+Subject: ARM: mvebu: Correct unit address for linksys
+
+From: Patrick Uiterwijk <patrick@puiterwijk.org>
+
+commit 199831c77c50e6913e893b6bc268ba9f4a9a2bf8 upstream.
+
+The USB2 port for Armada 38x is defined to be at 58000, not at
+50000.
+
+Fixes: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices")
+Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
+Acked-by: Imre Kaloz <kaloz@openwrt.org>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-385-linksys.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
++++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
+@@ -117,7 +117,7 @@
+ };
+
+ /* USB part of the eSATA/USB 2.0 port */
+- usb@50000 {
++ usb@58000 {
+ status = "okay";
+ };
+
--- /dev/null
+From 456e8d53482537616899a146b706eccd095404e6 Mon Sep 17 00:00:00 2001
+From: Nishanth Menon <nm@ti.com>
+Date: Fri, 11 Mar 2016 10:12:28 -0600
+Subject: ARM: OMAP2: Fix up interconnect barrier initialization for DRA7
+
+From: Nishanth Menon <nm@ti.com>
+
+commit 456e8d53482537616899a146b706eccd095404e6 upstream.
+
+The following commits:
+commit 3fa609755c11 ("ARM: omap2: restore OMAP4 barrier behaviour")
+commit f746929ffdc8 ("Revert "ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688"")
+and
+commit ea827ad5ffbb ("ARM: DRA7: Provide proper IO map table")
+came in around the same time, unfortunately this seem to have missed
+initializing the barrier for DRA7 platforms - omap5_map_io was reused
+for dra7 till it was split out by the last patch. barrier_init
+needs to be hence carried forward as it is valid for DRA7 family of
+processors as they are for OMAP5.
+
+Fixes: ea827ad5ffbb7 ("ARM: DRA7: Provide proper IO map table")
+Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Cc: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Nishanth Menon <nm@ti.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-omap2/io.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/mach-omap2/io.c
++++ b/arch/arm/mach-omap2/io.c
+@@ -368,6 +368,7 @@ void __init omap5_map_io(void)
+ void __init dra7xx_map_io(void)
+ {
+ iotable_init(dra7xx_io_desc, ARRAY_SIZE(dra7xx_io_desc));
++ omap_barriers_init();
+ }
+ #endif
+ /*
--- /dev/null
+From 3ca4a238106dedc285193ee47f494a6584b6fd2f Mon Sep 17 00:00:00 2001
+From: Lokesh Vutla <lokeshvutla@ti.com>
+Date: Sat, 26 Mar 2016 23:08:55 -0600
+Subject: ARM: OMAP2+: hwmod: Fix updating of sysconfig register
+
+From: Lokesh Vutla <lokeshvutla@ti.com>
+
+commit 3ca4a238106dedc285193ee47f494a6584b6fd2f upstream.
+
+Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle
+when necessary") talks about verification of sysconfig cache value before
+updating it, only during idle path. But the patch is adding the
+verification in the enable path. So, adding the check in a proper place
+as per the commit description.
+
+Not keeping this check during enable path as there is a chance of losing
+context and it is safe to do on idle as the context of the register will
+never be lost while the device is active.
+
+Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
+Acked-by: Tero Kristo <t-kristo@ti.com>
+Cc: Jon Hunter <jonathanh@nvidia.com>
+Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
+[paul@pwsan.com: appears to have been caused by my own mismerge of the
+ originally posted patch]
+Signed-off-by: Paul Walmsley <paul@pwsan.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-omap2/omap_hwmod.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/arm/mach-omap2/omap_hwmod.c
++++ b/arch/arm/mach-omap2/omap_hwmod.c
+@@ -1416,9 +1416,7 @@ static void _enable_sysc(struct omap_hwm
+ (sf & SYSC_HAS_CLOCKACTIVITY))
+ _set_clockactivity(oh, oh->class->sysc->clockact, &v);
+
+- /* If the cached value is the same as the new value, skip the write */
+- if (oh->_sysc_cache != v)
+- _write_sysconfig(v, oh);
++ _write_sysconfig(v, oh);
+
+ /*
+ * Set the autoidle bit only after setting the smartidle bit
+@@ -1481,7 +1479,9 @@ static void _idle_sysc(struct omap_hwmod
+ _set_master_standbymode(oh, idlemode, &v);
+ }
+
+- _write_sysconfig(v, oh);
++ /* If the cached value is the same as the new value, skip the write */
++ if (oh->_sysc_cache != v)
++ _write_sysconfig(v, oh);
+ }
+
+ /**
--- /dev/null
+From 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 Mon Sep 17 00:00:00 2001
+From: Jerome Marchand <jmarchan@redhat.com>
+Date: Wed, 6 Apr 2016 14:06:48 +0100
+Subject: assoc_array: don't call compare_object() on a node
+
+From: Jerome Marchand <jmarchan@redhat.com>
+
+commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream.
+
+Changes since V1: fixed the description and added KASan warning.
+
+In assoc_array_insert_into_terminal_node(), we call the
+compare_object() method on all non-empty slots, even when they're
+not leaves, passing a pointer to an unexpected structure to
+compare_object(). Currently it causes an out-of-bound read access
+in keyring_compare_object detected by KASan (see below). The issue
+is easily reproduced with keyutils testsuite.
+Only call compare_object() when the slot is a leave.
+
+KASan warning:
+==================================================================
+BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
+Read of size 8 by task keyctl/1655
+=============================================================================
+BUG kmalloc-192 (Not tainted): kasan: bad access detected
+-----------------------------------------------------------------------------
+
+Disabling lock debugging due to kernel taint
+INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
+ ___slab_alloc+0x563/0x5c0
+ __slab_alloc+0x51/0x90
+ kmem_cache_alloc_trace+0x263/0x300
+ assoc_array_insert+0xfd0/0x3a60
+ __key_link_begin+0xfc/0x270
+ key_create_or_update+0x459/0xaf0
+ SyS_add_key+0x1ba/0x350
+ entry_SYSCALL_64_fastpath+0x12/0x76
+INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
+INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1
+
+Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00 ...`............
+Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff ...`.......`....
+Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+CPU: 0 PID: 1655 Comm: keyctl Tainted: G B 4.5.0-rc4-kasan+ #291
+Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
+ 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
+ ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
+ ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
+Call Trace:
+ [<ffffffff81b60491>] dump_stack+0x85/0xc4
+ [<ffffffff815e2969>] print_trailer+0xf9/0x150
+ [<ffffffff815e9454>] object_err+0x34/0x40
+ [<ffffffff815ebe50>] kasan_report_error+0x230/0x550
+ [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210
+ [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70
+ [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240
+ [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240
+ [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60
+ [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70
+ [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270
+ [<ffffffff8199786c>] __key_link_begin+0xfc/0x270
+ [<ffffffff81993389>] key_create_or_update+0x459/0xaf0
+ [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10
+ [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0
+ [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0
+ [<ffffffff81534763>] ? memdup_user+0x53/0x80
+ [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350
+ [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0
+ [<ffffffff828bcf4e>] ? retint_user+0x18/0x23
+ [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580
+ [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19
+ [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76
+Memory state around the buggy address:
+ ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
+ ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
+>ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ^
+ ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
+==================================================================
+
+Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ lib/assoc_array.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/lib/assoc_array.c
++++ b/lib/assoc_array.c
+@@ -524,7 +524,9 @@ static bool assoc_array_insert_into_term
+ free_slot = i;
+ continue;
+ }
+- if (ops->compare_object(assoc_array_ptr_to_leaf(ptr), index_key)) {
++ if (assoc_array_ptr_is_leaf(ptr) &&
++ ops->compare_object(assoc_array_ptr_to_leaf(ptr),
++ index_key)) {
+ pr_devel("replace in slot %d\n", i);
+ edit->leaf_p = &node->slots[i];
+ edit->dead_leaf = node->slots[i];
--- /dev/null
+From a7297a6a3a3322b054592e8e988981d2f5f29cc4 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@canonical.com>
+Date: Fri, 15 Apr 2016 18:51:28 +0800
+Subject: block: loop: fix filesystem corruption in case of aio/dio
+
+From: Ming Lei <ming.lei@canonical.com>
+
+commit a7297a6a3a3322b054592e8e988981d2f5f29cc4 upstream.
+
+Starting from commit e36f620428(block: split bios to max possible length),
+block core starts to split bio in the middle of bvec.
+
+Unfortunately loop dio/aio doesn't consider this situation, and
+always treat 'iter.iov_offset' as zero. Then filesystem corruption
+is observed.
+
+This patch figures out the offset of the base bvevc via
+'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
+to iov iterator.
+
+Fixes: e36f6204288088f (block: split bios to max possible length)
+Cc: Keith Busch <keith.busch@intel.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Ming Lei <ming.lei@canonical.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/loop.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/block/loop.c
++++ b/drivers/block/loop.c
+@@ -488,6 +488,12 @@ static int lo_rw_aio(struct loop_device
+ bvec = __bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter);
+ iov_iter_bvec(&iter, ITER_BVEC | rw, bvec,
+ bio_segments(bio), blk_rq_bytes(cmd->rq));
++ /*
++ * This bio may be started from the middle of the 'bvec'
++ * because of bio splitting, so offset from the bvec must
++ * be passed to iov iterator
++ */
++ iter.iov_offset = bio->bi_iter.bi_bvec_done;
+
+ cmd->iocb.ki_pos = pos;
+ cmd->iocb.ki_filp = file;
--- /dev/null
+From b30a337ca27c4f40439e4bfb290cba5f88d73bb7 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@canonical.com>
+Date: Wed, 30 Mar 2016 08:46:31 +0800
+Subject: block: partition: initialize percpuref before sending out KOBJ_ADD
+
+From: Ming Lei <ming.lei@canonical.com>
+
+commit b30a337ca27c4f40439e4bfb290cba5f88d73bb7 upstream.
+
+The initialization of partition's percpu_ref should have been done before
+sending out KOBJ_ADD uevent, which may cause userspace to read partition
+table. So the uninitialized percpu_ref may be accessed in data path.
+
+This patch fixes this issue reported by Naveen.
+
+Reported-by: Naveen Kaje <nkaje@codeaurora.org>
+Tested-by: Naveen Kaje <nkaje@codeaurora.org>
+Fixes: 6c71013ecb7e2(block: partition: convert percpu ref)
+Signed-off-by: Ming Lei <ming.lei@canonical.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/partition-generic.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/block/partition-generic.c
++++ b/block/partition-generic.c
+@@ -350,15 +350,20 @@ struct hd_struct *add_partition(struct g
+ goto out_del;
+ }
+
++ err = hd_ref_init(p);
++ if (err) {
++ if (flags & ADDPART_FLAG_WHOLEDISK)
++ goto out_remove_file;
++ goto out_del;
++ }
++
+ /* everything is up and running, commence */
+ rcu_assign_pointer(ptbl->part[partno], p);
+
+ /* suppress uevent if the disk suppresses it */
+ if (!dev_get_uevent_suppress(ddev))
+ kobject_uevent(&pdev->kobj, KOBJ_ADD);
+-
+- if (!hd_ref_init(p))
+- return p;
++ return p;
+
+ out_free_info:
+ free_part_info(p);
+@@ -367,6 +372,8 @@ out_free_stats:
+ out_free:
+ kfree(p);
+ return ERR_PTR(err);
++out_remove_file:
++ device_remove_file(pdev, &dev_attr_whole_disk);
+ out_del:
+ kobject_put(p->holder_dir);
+ device_del(pdev);
--- /dev/null
+From 7cc8cbcf82d165dd658d89a7a287140948e76413 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Wed, 30 Mar 2016 09:46:23 +0200
+Subject: efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit 7cc8cbcf82d165dd658d89a7a287140948e76413 upstream.
+
+Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as
+MEMBLOCK_NOMAP") updated the mapping logic of both the RuntimeServices
+regions as well as the kernel's copy of the UEFI memory map to set the
+MEMBLOCK_NOMAP flag, which causes these regions to be omitted from the
+kernel direct mapping, and from being covered by a struct page.
+For the RuntimeServices regions, this is an obvious win, since the contents
+of these regions have significance to the firmware executable code itself,
+and are mapped in the EFI page tables using attributes that are described in
+the UEFI memory map, and which may differ from the attributes we use for
+mapping system RAM. It also prevents the contents from being modified
+inadvertently, since the EFI page tables are only live during runtime
+service invocations.
+
+None of these concerns apply to the allocation that covers the UEFI memory
+map, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on
+the region did allow us to use ioremap_cache() to map it both on arm64 and
+on ARM, since the latter does not allow ioremap_cache() to be used on
+regions that are covered by a struct page.
+
+The ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe,
+but in the mean time, it has been reported that commit 4dffbfc48d65 causes
+a regression on 64k granule kernels. This is due to the fact that, given
+the 64 KB page size, the region that we end up removing from the kernel
+direct mapping is rounded up to 64 KB, and this 64 KB page frame may be
+shared with the initrd when booting via GRUB (which does not align its
+EFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash
+the kernel as soon as it tries to access the initrd.
+
+Since the issue is specific to arm64, revert back to memblock_reserve()'ing
+the UEFI memory map when running on arm64. This is a temporary fix for v4.5
+and v4.6, and will be superseded in the v4.7 timeframe when we will be able
+to move back to memblock_reserve() unconditionally.
+
+Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
+Reported-by: Mark Salter <msalter@redhat.com>
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Acked-by: Will Deacon <will.deacon@arm.com>
+Cc: Leif Lindholm <leif.lindholm@linaro.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Jeremy Linton <jeremy.linton@arm.com>
+Cc: Mark Langsdorf <mlangsdo@redhat.com>
+Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/firmware/efi/arm-init.c | 18 +++++++++++++++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+--- a/drivers/firmware/efi/arm-init.c
++++ b/drivers/firmware/efi/arm-init.c
+@@ -203,7 +203,19 @@ void __init efi_init(void)
+
+ reserve_regions();
+ early_memunmap(memmap.map, params.mmap_size);
+- memblock_mark_nomap(params.mmap & PAGE_MASK,
+- PAGE_ALIGN(params.mmap_size +
+- (params.mmap & ~PAGE_MASK)));
++
++ if (IS_ENABLED(CONFIG_ARM)) {
++ /*
++ * ARM currently does not allow ioremap_cache() to be called on
++ * memory regions that are covered by struct page. So remove the
++ * UEFI memory map from the linear mapping.
++ */
++ memblock_mark_nomap(params.mmap & PAGE_MASK,
++ PAGE_ALIGN(params.mmap_size +
++ (params.mmap & ~PAGE_MASK)));
++ } else {
++ memblock_reserve(params.mmap & PAGE_MASK,
++ PAGE_ALIGN(params.mmap_size +
++ (params.mmap & ~PAGE_MASK)));
++ }
+ }
--- /dev/null
+From 1c5631c73fc2261a5df64a72c155cb53dcdc0c45 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Wed, 6 Apr 2016 09:37:22 +0100
+Subject: KVM: arm/arm64: Handle forward time correction gracefully
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 1c5631c73fc2261a5df64a72c155cb53dcdc0c45 upstream.
+
+On a host that runs NTP, corrections can have a direct impact on
+the background timer that we program on the behalf of a vcpu.
+
+In particular, NTP performing a forward correction will result in
+a timer expiring sooner than expected from a guest point of view.
+Not a big deal, we kick the vcpu anyway.
+
+But on wake-up, the vcpu thread is going to perform a check to
+find out whether or not it should block. And at that point, the
+timer check is going to say "timer has not expired yet, go back
+to sleep". This results in the timer event being lost forever.
+
+There are multiple ways to handle this. One would be record that
+the timer has expired and let kvm_cpu_has_pending_timer return
+true in that case, but that would be fairly invasive. Another is
+to check for the "short sleep" condition in the hrtimer callback,
+and restart the timer for the remaining time when the condition
+is detected.
+
+This patch implements the latter, with a bit of refactoring in
+order to avoid too much code duplication.
+
+Reported-by: Alexander Graf <agraf@suse.de>
+Reviewed-by: Alexander Graf <agraf@suse.de>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/arch_timer.c | 49 ++++++++++++++++++++++++++++++++++++----------
+ 1 file changed, 39 insertions(+), 10 deletions(-)
+
+--- a/virt/kvm/arm/arch_timer.c
++++ b/virt/kvm/arm/arch_timer.c
+@@ -86,6 +86,8 @@ static void kvm_timer_inject_irq_work(st
+ vcpu = container_of(work, struct kvm_vcpu, arch.timer_cpu.expired);
+ vcpu->arch.timer_cpu.armed = false;
+
++ WARN_ON(!kvm_timer_should_fire(vcpu));
++
+ /*
+ * If the vcpu is blocked we want to wake it up so that it will see
+ * the timer has expired when entering the guest.
+@@ -93,10 +95,46 @@ static void kvm_timer_inject_irq_work(st
+ kvm_vcpu_kick(vcpu);
+ }
+
++static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
++{
++ cycle_t cval, now;
++
++ cval = vcpu->arch.timer_cpu.cntv_cval;
++ now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
++
++ if (now < cval) {
++ u64 ns;
++
++ ns = cyclecounter_cyc2ns(timecounter->cc,
++ cval - now,
++ timecounter->mask,
++ &timecounter->frac);
++ return ns;
++ }
++
++ return 0;
++}
++
+ static enum hrtimer_restart kvm_timer_expire(struct hrtimer *hrt)
+ {
+ struct arch_timer_cpu *timer;
++ struct kvm_vcpu *vcpu;
++ u64 ns;
++
+ timer = container_of(hrt, struct arch_timer_cpu, timer);
++ vcpu = container_of(timer, struct kvm_vcpu, arch.timer_cpu);
++
++ /*
++ * Check that the timer has really expired from the guest's
++ * PoV (NTP on the host may have forced it to expire
++ * early). If we should have slept longer, restart it.
++ */
++ ns = kvm_timer_compute_delta(vcpu);
++ if (unlikely(ns)) {
++ hrtimer_forward_now(hrt, ns_to_ktime(ns));
++ return HRTIMER_RESTART;
++ }
++
+ queue_work(wqueue, &timer->expired);
+ return HRTIMER_NORESTART;
+ }
+@@ -170,8 +208,6 @@ static int kvm_timer_update_state(struct
+ void kvm_timer_schedule(struct kvm_vcpu *vcpu)
+ {
+ struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+- u64 ns;
+- cycle_t cval, now;
+
+ BUG_ON(timer_is_armed(timer));
+
+@@ -191,14 +227,7 @@ void kvm_timer_schedule(struct kvm_vcpu
+ return;
+
+ /* The timer has not yet expired, schedule a background timer */
+- cval = timer->cntv_cval;
+- now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
+-
+- ns = cyclecounter_cyc2ns(timecounter->cc,
+- cval - now,
+- timecounter->mask,
+- &timecounter->frac);
+- timer_arm(timer, ns);
++ timer_arm(timer, kvm_timer_compute_delta(vcpu));
+ }
+
+ void kvm_timer_unschedule(struct kvm_vcpu *vcpu)
--- /dev/null
+From fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 Mon Sep 17 00:00:00 2001
+From: David Matlack <dmatlack@google.com>
+Date: Wed, 30 Mar 2016 12:24:47 -0700
+Subject: kvm: x86: do not leak guest xcr0 into host interrupt handlers
+
+From: David Matlack <dmatlack@google.com>
+
+commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 upstream.
+
+An interrupt handler that uses the fpu can kill a KVM VM, if it runs
+under the following conditions:
+ - the guest's xcr0 register is loaded on the cpu
+ - the guest's fpu context is not loaded
+ - the host is using eagerfpu
+
+Note that the guest's xcr0 register and fpu context are not loaded as
+part of the atomic world switch into "guest mode". They are loaded by
+KVM while the cpu is still in "host mode".
+
+Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
+interrupt handler will look something like this:
+
+if (irq_fpu_usable()) {
+ kernel_fpu_begin();
+
+ [... code that uses the fpu ...]
+
+ kernel_fpu_end();
+}
+
+As long as the guest's fpu is not loaded and the host is using eager
+fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
+returns true). The interrupt handler proceeds to use the fpu with
+the guest's xcr0 live.
+
+kernel_fpu_begin() saves the current fpu context. If this uses
+XSAVE[OPT], it may leave the xsave area in an undesirable state.
+According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
+if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
+xcr0[i] == 0 following an XSAVE.
+
+kernel_fpu_end() restores the fpu context. Now if any bit i in
+XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
+fault is trapped and SIGSEGV is delivered to the current process.
+
+Only pre-4.2 kernels appear to be vulnerable to this sequence of
+events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly")
+from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.
+
+This patch fixes the bug by keeping the host's xcr0 loaded outside
+of the interrupts-disabled region where KVM switches into guest mode.
+
+Suggested-by: Andy Lutomirski <luto@amacapital.net>
+Signed-off-by: David Matlack <dmatlack@google.com>
+[Move load after goto cancel_injection. - Paolo]
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 10 ++++------
+ 1 file changed, 4 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -697,7 +697,6 @@ static int __kvm_set_xcr(struct kvm_vcpu
+ if ((xcr0 & XFEATURE_MASK_AVX512) != XFEATURE_MASK_AVX512)
+ return 1;
+ }
+- kvm_put_guest_xcr0(vcpu);
+ vcpu->arch.xcr0 = xcr0;
+
+ if ((xcr0 ^ old_xcr0) & XFEATURE_MASK_EXTEND)
+@@ -6569,8 +6568,6 @@ static int vcpu_enter_guest(struct kvm_v
+ kvm_x86_ops->prepare_guest_switch(vcpu);
+ if (vcpu->fpu_active)
+ kvm_load_guest_fpu(vcpu);
+- kvm_load_guest_xcr0(vcpu);
+-
+ vcpu->mode = IN_GUEST_MODE;
+
+ srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
+@@ -6593,6 +6590,8 @@ static int vcpu_enter_guest(struct kvm_v
+ goto cancel_injection;
+ }
+
++ kvm_load_guest_xcr0(vcpu);
++
+ if (req_immediate_exit)
+ smp_send_reschedule(vcpu->cpu);
+
+@@ -6642,6 +6641,8 @@ static int vcpu_enter_guest(struct kvm_v
+ vcpu->mode = OUTSIDE_GUEST_MODE;
+ smp_wmb();
+
++ kvm_put_guest_xcr0(vcpu);
++
+ /* Interrupt is enabled by handle_external_intr() */
+ kvm_x86_ops->handle_external_intr(vcpu);
+
+@@ -7289,7 +7290,6 @@ void kvm_load_guest_fpu(struct kvm_vcpu
+ * and assume host would use all available bits.
+ * Guest xcr0 would be loaded later.
+ */
+- kvm_put_guest_xcr0(vcpu);
+ vcpu->guest_fpu_loaded = 1;
+ __kernel_fpu_begin();
+ __copy_kernel_to_fpregs(&vcpu->arch.guest_fpu.state);
+@@ -7298,8 +7298,6 @@ void kvm_load_guest_fpu(struct kvm_vcpu
+
+ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
+ {
+- kvm_put_guest_xcr0(vcpu);
+-
+ if (!vcpu->guest_fpu_loaded) {
+ vcpu->fpu_counter = 0;
+ return;
--- /dev/null
+From 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Wed, 6 Apr 2016 16:12:08 +0200
+Subject: mmc: block: Use the mmc host device index as the mmcblk device index
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d upstream.
+
+Commit 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
+simultaneously") causes regressions for some platforms.
+
+These platforms relies on fixed mmcblk device indexes, instead of
+deploying the defacto standard with UUID/PARTUUID. In other words their
+rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2.
+
+Such guarantees have never been made by the kernel, but clearly the above
+commit changes the behaviour. More precisely, because of that the order
+changes of how cards becomes detected, so do their corresponding mmcblk
+device indexes.
+
+As the above commit significantly improves boot time for some platforms
+(magnitude of seconds), let's avoid reverting this change but instead
+restore the behaviour of how mmcblk device indexes becomes picked.
+
+By using the same index for the mmcblk device as for the corresponding mmc
+host device, the probe order of mmc host devices decides the index we get
+for the mmcblk device.
+
+For those platforms that suffers from a regression, one could expect that
+this updated behaviour should be sufficient to meet their expectations of
+"fixed" mmcblk device indexes.
+
+Another side effect from this change, is that the same index is used for
+the mmc host device, the mmcblk device and the mmc block queue. That
+should clarify their relationship.
+
+Reported-by: Peter Hurley <peter@hurleysoftware.com>
+Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Fixes: 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
+simultaneously")
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/card/block.c | 18 +-----------------
+ 1 file changed, 1 insertion(+), 17 deletions(-)
+
+--- a/drivers/mmc/card/block.c
++++ b/drivers/mmc/card/block.c
+@@ -86,7 +86,6 @@ static int max_devices;
+
+ /* TODO: Replace these with struct ida */
+ static DECLARE_BITMAP(dev_use, MAX_DEVICES);
+-static DECLARE_BITMAP(name_use, MAX_DEVICES);
+
+ /*
+ * There is one mmc_blk_data per slot.
+@@ -105,7 +104,6 @@ struct mmc_blk_data {
+ unsigned int usage;
+ unsigned int read_only;
+ unsigned int part_type;
+- unsigned int name_idx;
+ unsigned int reset_done;
+ #define MMC_BLK_READ BIT(0)
+ #define MMC_BLK_WRITE BIT(1)
+@@ -2202,19 +2200,6 @@ static struct mmc_blk_data *mmc_blk_allo
+ goto out;
+ }
+
+- /*
+- * !subname implies we are creating main mmc_blk_data that will be
+- * associated with mmc_card with dev_set_drvdata. Due to device
+- * partitions, devidx will not coincide with a per-physical card
+- * index anymore so we keep track of a name index.
+- */
+- if (!subname) {
+- md->name_idx = find_first_zero_bit(name_use, max_devices);
+- __set_bit(md->name_idx, name_use);
+- } else
+- md->name_idx = ((struct mmc_blk_data *)
+- dev_to_disk(parent)->private_data)->name_idx;
+-
+ md->area_type = area_type;
+
+ /*
+@@ -2264,7 +2249,7 @@ static struct mmc_blk_data *mmc_blk_allo
+ */
+
+ snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
+- "mmcblk%u%s", md->name_idx, subname ? subname : "");
++ "mmcblk%u%s", card->host->index, subname ? subname : "");
+
+ if (mmc_card_mmc(card))
+ blk_queue_logical_block_size(md->queue.queue,
+@@ -2418,7 +2403,6 @@ static void mmc_blk_remove_parts(struct
+ struct list_head *pos, *q;
+ struct mmc_blk_data *part_md;
+
+- __clear_bit(md->name_idx, name_use);
+ list_for_each_safe(pos, q, &md->part) {
+ part_md = list_entry(pos, struct mmc_blk_data, part);
+ list_del(pos);
--- /dev/null
+mmc-block-use-the-mmc-host-device-index-as-the-mmcblk-device-index.patch
+block-partition-initialize-percpuref-before-sending-out-kobj_add.patch
+block-loop-fix-filesystem-corruption-in-case-of-aio-dio.patch
+efi-arm64-don-t-apply-memblock_nomap-to-uefi-memory-map-mapping.patch
+x86-mce-avoid-using-object-after-free-in-genpool.patch
+kvm-x86-do-not-leak-guest-xcr0-into-host-interrupt-handlers.patch
+kvm-arm-arm64-handle-forward-time-correction-gracefully.patch
+arm-dts-am43x-epos-fix-clk-parent-for-synctimer.patch
+arm-dts-am43xx-fix-edma-memcpy-channel-allocation.patch
+arm-mvebu-correct-unit-address-for-linksys.patch
+arm-omap2-fix-up-interconnect-barrier-initialization-for-dra7.patch
+arm-omap2-hwmod-fix-updating-of-sysconfig-register.patch
+assoc_array-don-t-call-compare_object-on-a-node.patch
+usb-xhci-applying-xhci_pme_stuck_quirk-to-intel-bxt-b0-host.patch
+xhci-resume-usb-3-roothub-first.patch
+usb-host-xhci-add-a-new-quirk-xhci_no_64bit_support.patch
+usb-host-xhci-plat-fix-cannot-work-if-r-car-gen2-3-run-on-above-4gb-phys.patch
+usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch
+xhci-fix-10-second-timeout-on-removal-of-pci-hotpluggable-xhci-controllers.patch
+usb-host-xhci-plat-make-enum-xhci_plat_type-start-at-a-non-zero-value.patch
+usb-hcd-out-of-bounds-access-in-for_each_companion.patch
+usb-gadget-f_fs-fix-use-after-free.patch
--- /dev/null
+From 38740a5b87d53ceb89eb2c970150f6e94e00373a Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Thu, 14 Apr 2016 17:01:17 +0200
+Subject: usb: gadget: f_fs: Fix use-after-free
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 38740a5b87d53ceb89eb2c970150f6e94e00373a upstream.
+
+When using asynchronous read or write operations on the USB endpoints the
+issuer of the IO request is notified by calling the ki_complete() callback
+of the submitted kiocb when the URB has been completed.
+
+Calling this ki_complete() callback will free kiocb. Make sure that the
+structure is no longer accessed beyond that point, otherwise undefined
+behaviour might occur.
+
+Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/function/f_fs.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/gadget/function/f_fs.c
++++ b/drivers/usb/gadget/function/f_fs.c
+@@ -646,6 +646,7 @@ static void ffs_user_copy_worker(struct
+ work);
+ int ret = io_data->req->status ? io_data->req->status :
+ io_data->req->actual;
++ bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;
+
+ if (io_data->read && ret > 0) {
+ use_mm(io_data->mm);
+@@ -657,13 +658,11 @@ static void ffs_user_copy_worker(struct
+
+ io_data->kiocb->ki_complete(io_data->kiocb, ret, ret);
+
+- if (io_data->ffs->ffs_eventfd &&
+- !(io_data->kiocb->ki_flags & IOCB_EVENTFD))
++ if (io_data->ffs->ffs_eventfd && !kiocb_has_eventfd)
+ eventfd_signal(io_data->ffs->ffs_eventfd, 1);
+
+ usb_ep_free_request(io_data->ep, io_data->req);
+
+- io_data->kiocb->private = NULL;
+ if (io_data->read)
+ kfree(io_data->to_free);
+ kfree(io_data->buf);
--- /dev/null
+From e86103a75705c7c530768f4ffaba74cf382910f2 Mon Sep 17 00:00:00 2001
+From: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
+Date: Thu, 24 Mar 2016 03:30:07 -0700
+Subject: usb: hcd: out of bounds access in for_each_companion
+
+From: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
+
+commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream.
+
+On BXT platform Host Controller and Device Controller figure as
+same PCI device but with different device function. HCD should
+not pass data to Device Controller but only to Host Controllers.
+Checking if companion device is Host Controller, otherwise skip.
+
+Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hcd-pci.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/usb/core/hcd-pci.c
++++ b/drivers/usb/core/hcd-pci.c
+@@ -74,6 +74,15 @@ static void for_each_companion(struct pc
+ if (companion->bus != pdev->bus ||
+ PCI_SLOT(companion->devfn) != slot)
+ continue;
++
++ /*
++ * Companion device should be either UHCI,OHCI or EHCI host
++ * controller, otherwise skip.
++ */
++ if (companion->class != CL_UHCI && companion->class != CL_OHCI &&
++ companion->class != CL_EHCI)
++ continue;
++
+ companion_hcd = pci_get_drvdata(companion);
+ if (!companion_hcd || !companion_hcd->self.root_hub)
+ continue;
--- /dev/null
+From 0a380be8233dbf8dd20795b801c5d5d5ef3992f7 Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Fri, 8 Apr 2016 16:25:07 +0300
+Subject: usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT
+
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+commit 0a380be8233dbf8dd20795b801c5d5d5ef3992f7 upstream.
+
+On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of
+HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
+address memory pointers actually. So, in this case, this driver should
+call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
+Otherwise, the xHCI controller will be died after a usb device is
+connected if it runs on above 4GB physical memory environment.
+
+So, this patch adds a new quirk XHCI_NO_64BIT_SUPPORT to resolve
+such an issue.
+
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci.c | 10 ++++++++++
+ drivers/usb/host/xhci.h | 1 +
+ 2 files changed, 11 insertions(+)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -4944,6 +4944,16 @@ int xhci_gen_setup(struct usb_hcd *hcd,
+ return retval;
+ xhci_dbg(xhci, "Reset complete\n");
+
++ /*
++ * On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0)
++ * of HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
++ * address memory pointers actually. So, this driver clears the AC64
++ * bit of xhci->hcc_params to call dma_set_coherent_mask(dev,
++ * DMA_BIT_MASK(32)) in this xhci_gen_setup().
++ */
++ if (xhci->quirks & XHCI_NO_64BIT_SUPPORT)
++ xhci->hcc_params &= ~BIT(0);
++
+ /* Set dma_mask and coherent_dma_mask to 64-bits,
+ * if xHC supports 64-bit addressing */
+ if (HCC_64BIT_ADDR(xhci->hcc_params) &&
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1632,6 +1632,7 @@ struct xhci_hcd {
+ #define XHCI_PME_STUCK_QUIRK (1 << 20)
+ #define XHCI_MTK_HOST (1 << 21)
+ #define XHCI_SSIC_PORT_UNUSED (1 << 22)
++#define XHCI_NO_64BIT_SUPPORT (1 << 23)
+ unsigned int num_active_eps;
+ unsigned int limit_active_eps;
+ /* There are two roothubs to keep track of bus suspend info for */
--- /dev/null
+From 5ad3b03e4910f9f62342956ecdc758c7af6b8699 Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Fri, 8 Apr 2016 16:25:08 +0300
+Subject: usb: host: xhci-plat: fix cannot work if R-Car Gen2/3 run on above 4GB phys
+
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+commit 5ad3b03e4910f9f62342956ecdc758c7af6b8699 upstream.
+
+This patch fixes an issue that cannot work if R-Car Gen2/3 run on
+above 4GB physical memory environment to use a quirk XHCI_NO_64BIT_SUPPORT.
+
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-plat.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/usb/host/xhci-plat.c
++++ b/drivers/usb/host/xhci-plat.c
+@@ -39,12 +39,25 @@ static const struct xhci_driver_override
+
+ static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
+ {
++ struct usb_hcd *hcd = xhci_to_hcd(xhci);
++
+ /*
+ * As of now platform drivers don't provide MSI support so we ensure
+ * here that the generic code does not try to make a pci_dev from our
+ * dev struct in order to setup MSI
+ */
+ xhci->quirks |= XHCI_PLAT;
++
++ /*
++ * On R-Car Gen2 and Gen3, the AC64 bit (bit 0) of HCCPARAMS1 is set
++ * to 1. However, these SoCs don't support 64-bit address memory
++ * pointers. So, this driver clears the AC64 bit of xhci->hcc_params
++ * to call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in
++ * xhci_gen_setup().
++ */
++ if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2) ||
++ xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3))
++ xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
+ }
+
+ /* called during probe() after chip reset completes */
--- /dev/null
+From f9a85f6e61c695daeb427dfc6c1d5a279654207b Mon Sep 17 00:00:00 2001
+From: Peter Griffin <peter.griffin@linaro.org>
+Date: Wed, 13 Apr 2016 19:58:44 +0300
+Subject: usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value
+
+From: Peter Griffin <peter.griffin@linaro.org>
+
+commit f9a85f6e61c695daeb427dfc6c1d5a279654207b upstream.
+
+Otherwise generic-xhci and xhci-platform which have no data get wrongly
+detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is().
+
+This fixes a regression in v4.5 for STiH407 family SoC's which use the
+synopsis dwc3 IP, whereby the disable_clk error path gets taken due to
+wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd never
+gets added.
+
+I suspect this will also fix other dwc3 DT platforms such as Exynos,
+although I've only tested on STih410 SoC.
+
+Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv")
+Cc: gregory.clement@free-electrons.com
+Cc: yoshihiro.shimoda.uh@renesas.com
+Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-plat.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-plat.h
++++ b/drivers/usb/host/xhci-plat.h
+@@ -14,7 +14,7 @@
+ #include "xhci.h" /* for hcd_to_xhci() */
+
+ enum xhci_plat_type {
+- XHCI_PLAT_TYPE_MARVELL_ARMADA,
++ XHCI_PLAT_TYPE_MARVELL_ARMADA = 1,
+ XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
+ XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
+ };
--- /dev/null
+From 0d46faca6f887a849efb07c1655b5a9f7c288b45 Mon Sep 17 00:00:00 2001
+From: Rafal Redzimski <rafal.f.redzimski@intel.com>
+Date: Fri, 8 Apr 2016 16:25:05 +0300
+Subject: usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host
+
+From: Rafal Redzimski <rafal.f.redzimski@intel.com>
+
+commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream.
+
+Broxton B0 also requires XHCI_PME_STUCK_QUIRK.
+Adding PCI device ID for Broxton B and adding to quirk.
+
+Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
+Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
+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 | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -48,6 +48,7 @@
+ #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI 0xa12f
+ #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
+ #define PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI 0x0aa8
++#define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
+
+ static const char hcd_name[] = "xhci_hcd";
+
+@@ -155,7 +156,8 @@ static void xhci_pci_quirks(struct devic
+ (pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
+- pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI)) {
++ pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI ||
++ pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI)) {
+ xhci->quirks |= XHCI_PME_STUCK_QUIRK;
+ }
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
--- /dev/null
+From 71504062a7c34838c3fccd92c447f399d3cb5797 Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Fri, 8 Apr 2016 16:25:09 +0300
+Subject: usb: xhci: fix wild pointers in xhci_mem_cleanup
+
+From: Lu Baolu <baolu.lu@linux.intel.com>
+
+commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream.
+
+This patch fixes some wild pointers produced by xhci_mem_cleanup.
+These wild pointers will cause system crash if xhci_mem_cleanup()
+is called twice.
+
+Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-mem.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -1873,6 +1873,12 @@ no_bw:
+ kfree(xhci->rh_bw);
+ kfree(xhci->ext_caps);
+
++ xhci->usb2_ports = NULL;
++ xhci->usb3_ports = NULL;
++ xhci->port_array = NULL;
++ xhci->rh_bw = NULL;
++ xhci->ext_caps = NULL;
++
+ xhci->page_size = 0;
+ xhci->page_shift = 0;
+ xhci->bus_state[0].bus_suspended = 0;
--- /dev/null
+From a3125494cff084b098c80bb36fbe2061ffed9d52 Mon Sep 17 00:00:00 2001
+From: Tony Luck <tony.luck@intel.com>
+Date: Wed, 6 Apr 2016 10:05:16 +0200
+Subject: x86/mce: Avoid using object after free in genpool
+
+From: Tony Luck <tony.luck@intel.com>
+
+commit a3125494cff084b098c80bb36fbe2061ffed9d52 upstream.
+
+When we loop over all queued machine check error records to pass them
+to the registered notifiers we use llist_for_each_entry(). But the loop
+calls gen_pool_free() for the entry in the body of the loop - and then
+the iterator looks at node->next after the free.
+
+Use llist_for_each_entry_safe() instead.
+
+Signed-off-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: Gong Chen <gong.chen@linux.intel.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-edac <linux-edac@vger.kernel.org>
+Link: http://lkml.kernel.org/r/0205920@agluck-desk.sc.intel.com
+Link: http://lkml.kernel.org/r/1459929916-12852-4-git-send-email-bp@alien8.de
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/mcheck/mce-genpool.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
++++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
+@@ -29,7 +29,7 @@ static char gen_pool_buf[MCE_POOLSZ];
+ void mce_gen_pool_process(void)
+ {
+ struct llist_node *head;
+- struct mce_evt_llist *node;
++ struct mce_evt_llist *node, *tmp;
+ struct mce *mce;
+
+ head = llist_del_all(&mce_event_llist);
+@@ -37,7 +37,7 @@ void mce_gen_pool_process(void)
+ return;
+
+ head = llist_reverse_order(head);
+- llist_for_each_entry(node, head, llnode) {
++ llist_for_each_entry_safe(node, tmp, head, llnode) {
+ mce = &node->mce;
+ atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
+ gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node));
--- /dev/null
+From 98d74f9ceaefc2b6c4a6440050163a83be0abede Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 8 Apr 2016 16:25:10 +0300
+Subject: xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 98d74f9ceaefc2b6c4a6440050163a83be0abede upstream.
+
+PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
+remove the xhci controller from the PCI bus when the last USB device is
+disconnected.
+
+Add a flag to indicate that the host is being removed to avoid queueing
+configure_endpoint commands for the dropped endpoints.
+For PCI hotplugged controllers this will prevent 5 second command timeouts
+For static xhci controllers the configure_endpoint command is not needed
+in the removal case as everything will be returned, freed, and the
+controller is reset.
+
+For now the flag is only set for PCI connected host controllers.
+
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 1 +
+ drivers/usb/host/xhci-ring.c | 3 ++-
+ drivers/usb/host/xhci.c | 8 +++++---
+ drivers/usb/host/xhci.h | 1 +
+ 4 files changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -304,6 +304,7 @@ static void xhci_pci_remove(struct pci_d
+ struct xhci_hcd *xhci;
+
+ xhci = hcd_to_xhci(pci_get_drvdata(dev));
++ xhci->xhc_state |= XHCI_STATE_REMOVING;
+ if (xhci->shared_hcd) {
+ usb_remove_hcd(xhci->shared_hcd);
+ usb_put_hcd(xhci->shared_hcd);
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -4014,7 +4014,8 @@ static int queue_command(struct xhci_hcd
+ int reserved_trbs = xhci->cmd_ring_reserved_trbs;
+ int ret;
+
+- if (xhci->xhc_state) {
++ if ((xhci->xhc_state & XHCI_STATE_DYING) ||
++ (xhci->xhc_state & XHCI_STATE_HALTED)) {
+ xhci_dbg(xhci, "xHCI dying or halted, can't queue_command\n");
+ return -ESHUTDOWN;
+ }
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -147,7 +147,8 @@ static int xhci_start(struct xhci_hcd *x
+ "waited %u microseconds.\n",
+ XHCI_MAX_HALT_USEC);
+ if (!ret)
+- xhci->xhc_state &= ~(XHCI_STATE_HALTED | XHCI_STATE_DYING);
++ /* clear state flags. Including dying, halted or removing */
++ xhci->xhc_state = 0;
+
+ return ret;
+ }
+@@ -2770,7 +2771,8 @@ int xhci_check_bandwidth(struct usb_hcd
+ if (ret <= 0)
+ return ret;
+ xhci = hcd_to_xhci(hcd);
+- if (xhci->xhc_state & XHCI_STATE_DYING)
++ if ((xhci->xhc_state & XHCI_STATE_DYING) ||
++ (xhci->xhc_state & XHCI_STATE_REMOVING))
+ return -ENODEV;
+
+ xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev);
+@@ -3817,7 +3819,7 @@ static int xhci_setup_device(struct usb_
+
+ mutex_lock(&xhci->mutex);
+
+- if (xhci->xhc_state) /* dying or halted */
++ if (xhci->xhc_state) /* dying, removing or halted */
+ goto out;
+
+ if (!udev->slot_id) {
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1596,6 +1596,7 @@ struct xhci_hcd {
+ */
+ #define XHCI_STATE_DYING (1 << 0)
+ #define XHCI_STATE_HALTED (1 << 1)
++#define XHCI_STATE_REMOVING (1 << 2)
+ /* Statistics */
+ int error_bitmask;
+ unsigned int quirks;
--- /dev/null
+From 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 8 Apr 2016 16:25:06 +0300
+Subject: xhci: resume USB 3 roothub first
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 upstream.
+
+Give USB3 devices a better chance to enumerate at USB 3 speeds if
+they are connected to a suspended host.
+Solves an issue with NEC uPD720200 host hanging when partially
+enumerating a USB3 device as USB2 after host controller runtime resume.
+
+Tested-by: Mike Murdoch <main.haarp@gmail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -1108,8 +1108,8 @@ int xhci_resume(struct xhci_hcd *xhci, b
+ /* Resume root hubs only when have pending events. */
+ status = readl(&xhci->op_regs->status);
+ if (status & STS_EINT) {
+- usb_hcd_resume_root_hub(hcd);
+ usb_hcd_resume_root_hub(xhci->shared_hcd);
++ usb_hcd_resume_root_hub(hcd);
+ }
+ }
+
+@@ -1124,10 +1124,10 @@ int xhci_resume(struct xhci_hcd *xhci, b
+
+ /* Re-enable port polling. */
+ xhci_dbg(xhci, "%s: starting port polling.\n", __func__);
+- set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
+- usb_hcd_poll_rh_status(hcd);
+ set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
+ usb_hcd_poll_rh_status(xhci->shared_hcd);
++ set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
++ usb_hcd_poll_rh_status(hcd);
+
+ return retval;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
