From: Greg Kroah-Hartman Date: Wed, 27 Apr 2016 23:57:50 +0000 (-0700) Subject: 4.5-stable patches X-Git-Tag: v3.14.68~53 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=09bc1d13deed312651432c806c5c5e972db36bdd;p=thirdparty%2Fkernel%2Fstable-queue.git 4.5-stable patches added patches: 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 block-loop-fix-filesystem-corruption-in-case-of-aio-dio.patch block-partition-initialize-percpuref-before-sending-out-kobj_add.patch efi-arm64-don-t-apply-memblock_nomap-to-uefi-memory-map-mapping.patch kvm-arm-arm64-handle-forward-time-correction-gracefully.patch kvm-x86-do-not-leak-guest-xcr0-into-host-interrupt-handlers.patch mmc-block-use-the-mmc-host-device-index-as-the-mmcblk-device-index.patch usb-gadget-f_fs-fix-use-after-free.patch usb-hcd-out-of-bounds-access-in-for_each_companion.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-host-xhci-plat-make-enum-xhci_plat_type-start-at-a-non-zero-value.patch usb-xhci-applying-xhci_pme_stuck_quirk-to-intel-bxt-b0-host.patch usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch x86-mce-avoid-using-object-after-free-in-genpool.patch xhci-fix-10-second-timeout-on-removal-of-pci-hotpluggable-xhci-controllers.patch xhci-resume-usb-3-roothub-first.patch --- diff --git a/queue-3.14/series b/queue-3.14/series new file mode 100644 index 00000000000..b8885f4fcf0 --- /dev/null +++ b/queue-3.14/series @@ -0,0 +1,5 @@ +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 diff --git a/queue-4.4/series b/queue-4.4/series new file mode 100644 index 00000000000..a6c2b976428 --- /dev/null +++ b/queue-4.4/series @@ -0,0 +1,17 @@ +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 diff --git a/queue-4.5/arm-dts-am43x-epos-fix-clk-parent-for-synctimer.patch b/queue-4.5/arm-dts-am43x-epos-fix-clk-parent-for-synctimer.patch new file mode 100644 index 00000000000..757525744dc --- /dev/null +++ b/queue-4.5/arm-dts-am43x-epos-fix-clk-parent-for-synctimer.patch @@ -0,0 +1,38 @@ +From cfe1580a6415bc37fd62d79eb8102a618f7650b2 Mon Sep 17 00:00:00 2001 +From: Lokesh Vutla +Date: Tue, 8 Mar 2016 12:24:35 +0530 +Subject: ARM: dts: AM43x-epos: Fix clk parent for synctimer + +From: Lokesh Vutla + +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 +Signed-off-by: Lokesh Vutla +Signed-off-by: Tony Lindgren +Signed-off-by: Greg Kroah-Hartman + +--- + 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>; ++}; diff --git a/queue-4.5/arm-dts-am43xx-fix-edma-memcpy-channel-allocation.patch b/queue-4.5/arm-dts-am43xx-fix-edma-memcpy-channel-allocation.patch new file mode 100644 index 00000000000..047e53c73c1 --- /dev/null +++ b/queue-4.5/arm-dts-am43xx-fix-edma-memcpy-channel-allocation.patch @@ -0,0 +1,39 @@ +From d41676ddddef27224a398609d874055866694cfa Mon Sep 17 00:00:00 2001 +From: Tero Kristo +Date: Mon, 14 Mar 2016 11:01:50 +0200 +Subject: ARM: dts: am43xx: fix edma memcpy channel allocation + +From: Tero Kristo + +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 +Suggested-by: Peter Ujfalusi +Signed-off-by: Tony Lindgren +Signed-off-by: Greg Kroah-Hartman + +--- + 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 { diff --git a/queue-4.5/arm-mvebu-correct-unit-address-for-linksys.patch b/queue-4.5/arm-mvebu-correct-unit-address-for-linksys.patch new file mode 100644 index 00000000000..f30b3548458 --- /dev/null +++ b/queue-4.5/arm-mvebu-correct-unit-address-for-linksys.patch @@ -0,0 +1,33 @@ +From 199831c77c50e6913e893b6bc268ba9f4a9a2bf8 Mon Sep 17 00:00:00 2001 +From: Patrick Uiterwijk +Date: Tue, 29 Mar 2016 16:57:40 +0000 +Subject: ARM: mvebu: Correct unit address for linksys + +From: Patrick Uiterwijk + +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 +Acked-by: Imre Kaloz +Signed-off-by: Gregory CLEMENT +Signed-off-by: Greg Kroah-Hartman + +--- + 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"; + }; + diff --git a/queue-4.5/arm-omap2-fix-up-interconnect-barrier-initialization-for-dra7.patch b/queue-4.5/arm-omap2-fix-up-interconnect-barrier-initialization-for-dra7.patch new file mode 100644 index 00000000000..4cf5a08a8db --- /dev/null +++ b/queue-4.5/arm-omap2-fix-up-interconnect-barrier-initialization-for-dra7.patch @@ -0,0 +1,43 @@ +From 456e8d53482537616899a146b706eccd095404e6 Mon Sep 17 00:00:00 2001 +From: Nishanth Menon +Date: Fri, 11 Mar 2016 10:12:28 -0600 +Subject: ARM: OMAP2: Fix up interconnect barrier initialization for DRA7 + +From: Nishanth Menon + +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 +Reported-by: Tomi Valkeinen +Cc: Russell King +Signed-off-by: Nishanth Menon +Reviewed-by: Laurent Pinchart +Signed-off-by: Tony Lindgren +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + /* diff --git a/queue-4.5/arm-omap2-hwmod-fix-updating-of-sysconfig-register.patch b/queue-4.5/arm-omap2-hwmod-fix-updating-of-sysconfig-register.patch new file mode 100644 index 00000000000..8138cc471d3 --- /dev/null +++ b/queue-4.5/arm-omap2-hwmod-fix-updating-of-sysconfig-register.patch @@ -0,0 +1,56 @@ +From 3ca4a238106dedc285193ee47f494a6584b6fd2f Mon Sep 17 00:00:00 2001 +From: Lokesh Vutla +Date: Sat, 26 Mar 2016 23:08:55 -0600 +Subject: ARM: OMAP2+: hwmod: Fix updating of sysconfig register + +From: Lokesh Vutla + +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 +Acked-by: Tero Kristo +Cc: Jon Hunter +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + + /** diff --git a/queue-4.5/assoc_array-don-t-call-compare_object-on-a-node.patch b/queue-4.5/assoc_array-don-t-call-compare_object-on-a-node.patch new file mode 100644 index 00000000000..6766f6ce993 --- /dev/null +++ b/queue-4.5/assoc_array-don-t-call-compare_object-on-a-node.patch @@ -0,0 +1,112 @@ +From 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 Mon Sep 17 00:00:00 2001 +From: Jerome Marchand +Date: Wed, 6 Apr 2016 14:06:48 +0100 +Subject: assoc_array: don't call compare_object() on a node + +From: Jerome Marchand + +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: + [] dump_stack+0x85/0xc4 + [] print_trailer+0xf9/0x150 + [] object_err+0x34/0x40 + [] kasan_report_error+0x230/0x550 + [] ? keyring_get_key_chunk+0x13e/0x210 + [] __asan_report_load_n_noabort+0x5d/0x70 + [] ? keyring_compare_object+0x213/0x240 + [] keyring_compare_object+0x213/0x240 + [] assoc_array_insert+0x86c/0x3a60 + [] ? assoc_array_cancel_edit+0x70/0x70 + [] ? __key_link_begin+0x20d/0x270 + [] __key_link_begin+0xfc/0x270 + [] key_create_or_update+0x459/0xaf0 + [] ? trace_hardirqs_on+0xd/0x10 + [] ? key_type_lookup+0xc0/0xc0 + [] ? lookup_user_key+0x13d/0xcd0 + [] ? memdup_user+0x53/0x80 + [] SyS_add_key+0x1ba/0x350 + [] ? key_get_type_from_user.constprop.6+0xa0/0xa0 + [] ? retint_user+0x18/0x23 + [] ? trace_hardirqs_on_caller+0x3fe/0x580 + [] ? trace_hardirqs_on_thunk+0x17/0x19 + [] 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 +Signed-off-by: David Howells +Signed-off-by: Greg Kroah-Hartman + +--- + 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]; diff --git a/queue-4.5/block-loop-fix-filesystem-corruption-in-case-of-aio-dio.patch b/queue-4.5/block-loop-fix-filesystem-corruption-in-case-of-aio-dio.patch new file mode 100644 index 00000000000..5d68a769321 --- /dev/null +++ b/queue-4.5/block-loop-fix-filesystem-corruption-in-case-of-aio-dio.patch @@ -0,0 +1,46 @@ +From a7297a6a3a3322b054592e8e988981d2f5f29cc4 Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Fri, 15 Apr 2016 18:51:28 +0800 +Subject: block: loop: fix filesystem corruption in case of aio/dio + +From: Ming Lei + +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 +Cc: Al Viro +Signed-off-by: Ming Lei +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.5/block-partition-initialize-percpuref-before-sending-out-kobj_add.patch b/queue-4.5/block-partition-initialize-percpuref-before-sending-out-kobj_add.patch new file mode 100644 index 00000000000..1ee515fe323 --- /dev/null +++ b/queue-4.5/block-partition-initialize-percpuref-before-sending-out-kobj_add.patch @@ -0,0 +1,61 @@ +From b30a337ca27c4f40439e4bfb290cba5f88d73bb7 Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Wed, 30 Mar 2016 08:46:31 +0800 +Subject: block: partition: initialize percpuref before sending out KOBJ_ADD + +From: Ming Lei + +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 +Tested-by: Naveen Kaje +Fixes: 6c71013ecb7e2(block: partition: convert percpu ref) +Signed-off-by: Ming Lei +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.5/efi-arm64-don-t-apply-memblock_nomap-to-uefi-memory-map-mapping.patch b/queue-4.5/efi-arm64-don-t-apply-memblock_nomap-to-uefi-memory-map-mapping.patch new file mode 100644 index 00000000000..1cc3714d765 --- /dev/null +++ b/queue-4.5/efi-arm64-don-t-apply-memblock_nomap-to-uefi-memory-map-mapping.patch @@ -0,0 +1,82 @@ +From 7cc8cbcf82d165dd658d89a7a287140948e76413 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +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 + +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 +Signed-off-by: Ard Biesheuvel +Acked-by: Will Deacon +Cc: Leif Lindholm +Cc: Mark Rutland +Cc: Jeremy Linton +Cc: Mark Langsdorf +Signed-off-by: Matt Fleming +Signed-off-by: Greg Kroah-Hartman + +--- + 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))); ++ } + } diff --git a/queue-4.5/kvm-arm-arm64-handle-forward-time-correction-gracefully.patch b/queue-4.5/kvm-arm-arm64-handle-forward-time-correction-gracefully.patch new file mode 100644 index 00000000000..5fc5d2ebd87 --- /dev/null +++ b/queue-4.5/kvm-arm-arm64-handle-forward-time-correction-gracefully.patch @@ -0,0 +1,124 @@ +From 1c5631c73fc2261a5df64a72c155cb53dcdc0c45 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Wed, 6 Apr 2016 09:37:22 +0100 +Subject: KVM: arm/arm64: Handle forward time correction gracefully + +From: Marc Zyngier + +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 +Reviewed-by: Alexander Graf +Signed-off-by: Marc Zyngier +Signed-off-by: Christoffer Dall +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.5/kvm-x86-do-not-leak-guest-xcr0-into-host-interrupt-handlers.patch b/queue-4.5/kvm-x86-do-not-leak-guest-xcr0-into-host-interrupt-handlers.patch new file mode 100644 index 00000000000..e89a2bffa03 --- /dev/null +++ b/queue-4.5/kvm-x86-do-not-leak-guest-xcr0-into-host-interrupt-handlers.patch @@ -0,0 +1,116 @@ +From fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 Mon Sep 17 00:00:00 2001 +From: David Matlack +Date: Wed, 30 Mar 2016 12:24:47 -0700 +Subject: kvm: x86: do not leak guest xcr0 into host interrupt handlers + +From: David Matlack + +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 +Signed-off-by: David Matlack +[Move load after goto cancel_injection. - Paolo] +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.5/mmc-block-use-the-mmc-host-device-index-as-the-mmcblk-device-index.patch b/queue-4.5/mmc-block-use-the-mmc-host-device-index-as-the-mmcblk-device-index.patch new file mode 100644 index 00000000000..255271a25da --- /dev/null +++ b/queue-4.5/mmc-block-use-the-mmc-host-device-index-as-the-mmcblk-device-index.patch @@ -0,0 +1,104 @@ +From 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d Mon Sep 17 00:00:00 2001 +From: Ulf Hansson +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 + +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 +Reported-by: Laszlo Fiat +Cc: Linus Torvalds +Fixes: 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards +simultaneously") +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.5/series b/queue-4.5/series new file mode 100644 index 00000000000..c7e3a65a308 --- /dev/null +++ b/queue-4.5/series @@ -0,0 +1,22 @@ +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 diff --git a/queue-4.5/usb-gadget-f_fs-fix-use-after-free.patch b/queue-4.5/usb-gadget-f_fs-fix-use-after-free.patch new file mode 100644 index 00000000000..e558d7e3dec --- /dev/null +++ b/queue-4.5/usb-gadget-f_fs-fix-use-after-free.patch @@ -0,0 +1,51 @@ +From 38740a5b87d53ceb89eb2c970150f6e94e00373a Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Thu, 14 Apr 2016 17:01:17 +0200 +Subject: usb: gadget: f_fs: Fix use-after-free + +From: Lars-Peter Clausen + +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 +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.5/usb-hcd-out-of-bounds-access-in-for_each_companion.patch b/queue-4.5/usb-hcd-out-of-bounds-access-in-for_each_companion.patch new file mode 100644 index 00000000000..ceffdd68a57 --- /dev/null +++ b/queue-4.5/usb-hcd-out-of-bounds-access-in-for_each_companion.patch @@ -0,0 +1,40 @@ +From e86103a75705c7c530768f4ffaba74cf382910f2 Mon Sep 17 00:00:00 2001 +From: Robert Dobrowolski +Date: Thu, 24 Mar 2016 03:30:07 -0700 +Subject: usb: hcd: out of bounds access in for_each_companion + +From: Robert Dobrowolski + +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 +Acked-by: Alan Stern +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.5/usb-host-xhci-add-a-new-quirk-xhci_no_64bit_support.patch b/queue-4.5/usb-host-xhci-add-a-new-quirk-xhci_no_64bit_support.patch new file mode 100644 index 00000000000..f6bfa975ec2 --- /dev/null +++ b/queue-4.5/usb-host-xhci-add-a-new-quirk-xhci_no_64bit_support.patch @@ -0,0 +1,59 @@ +From 0a380be8233dbf8dd20795b801c5d5d5ef3992f7 Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +Date: Fri, 8 Apr 2016 16:25:07 +0300 +Subject: usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT + +From: Yoshihiro Shimoda + +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 +Reviewed-by: Felipe Balbi +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-4.5/usb-host-xhci-plat-fix-cannot-work-if-r-car-gen2-3-run-on-above-4gb-phys.patch b/queue-4.5/usb-host-xhci-plat-fix-cannot-work-if-r-car-gen2-3-run-on-above-4gb-phys.patch new file mode 100644 index 00000000000..6ef07db09f2 --- /dev/null +++ b/queue-4.5/usb-host-xhci-plat-fix-cannot-work-if-r-car-gen2-3-run-on-above-4gb-phys.patch @@ -0,0 +1,50 @@ +From 5ad3b03e4910f9f62342956ecdc758c7af6b8699 Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +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 + +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 +Reviewed-by: Felipe Balbi +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-4.5/usb-host-xhci-plat-make-enum-xhci_plat_type-start-at-a-non-zero-value.patch b/queue-4.5/usb-host-xhci-plat-make-enum-xhci_plat_type-start-at-a-non-zero-value.patch new file mode 100644 index 00000000000..64ce05d6a2a --- /dev/null +++ b/queue-4.5/usb-host-xhci-plat-make-enum-xhci_plat_type-start-at-a-non-zero-value.patch @@ -0,0 +1,43 @@ +From f9a85f6e61c695daeb427dfc6c1d5a279654207b Mon Sep 17 00:00:00 2001 +From: Peter Griffin +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 + +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 +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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, + }; diff --git a/queue-4.5/usb-xhci-applying-xhci_pme_stuck_quirk-to-intel-bxt-b0-host.patch b/queue-4.5/usb-xhci-applying-xhci_pme_stuck_quirk-to-intel-bxt-b0-host.patch new file mode 100644 index 00000000000..dd3025785ab --- /dev/null +++ b/queue-4.5/usb-xhci-applying-xhci_pme_stuck_quirk-to-intel-bxt-b0-host.patch @@ -0,0 +1,41 @@ +From 0d46faca6f887a849efb07c1655b5a9f7c288b45 Mon Sep 17 00:00:00 2001 +From: Rafal Redzimski +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 + +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 +Signed-off-by: Robert Dobrowolski +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman + +--- + 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 && diff --git a/queue-4.5/usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch b/queue-4.5/usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch new file mode 100644 index 00000000000..0bcee09d0c2 --- /dev/null +++ b/queue-4.5/usb-xhci-fix-wild-pointers-in-xhci_mem_cleanup.patch @@ -0,0 +1,38 @@ +From 71504062a7c34838c3fccd92c447f399d3cb5797 Mon Sep 17 00:00:00 2001 +From: Lu Baolu +Date: Fri, 8 Apr 2016 16:25:09 +0300 +Subject: usb: xhci: fix wild pointers in xhci_mem_cleanup + +From: Lu Baolu + +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 +Signed-off-by: Lu Baolu +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.5/x86-mce-avoid-using-object-after-free-in-genpool.patch b/queue-4.5/x86-mce-avoid-using-object-after-free-in-genpool.patch new file mode 100644 index 00000000000..a8677577d48 --- /dev/null +++ b/queue-4.5/x86-mce-avoid-using-object-after-free-in-genpool.patch @@ -0,0 +1,52 @@ +From a3125494cff084b098c80bb36fbe2061ffed9d52 Mon Sep 17 00:00:00 2001 +From: Tony Luck +Date: Wed, 6 Apr 2016 10:05:16 +0200 +Subject: x86/mce: Avoid using object after free in genpool + +From: Tony Luck + +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 +Signed-off-by: Borislav Petkov +Cc: Gong Chen +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: linux-edac +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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)); diff --git a/queue-4.5/xhci-fix-10-second-timeout-on-removal-of-pci-hotpluggable-xhci-controllers.patch b/queue-4.5/xhci-fix-10-second-timeout-on-removal-of-pci-hotpluggable-xhci-controllers.patch new file mode 100644 index 00000000000..39fc9500b13 --- /dev/null +++ b/queue-4.5/xhci-fix-10-second-timeout-on-removal-of-pci-hotpluggable-xhci-controllers.patch @@ -0,0 +1,96 @@ +From 98d74f9ceaefc2b6c4a6440050163a83be0abede Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +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 + +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 +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.5/xhci-resume-usb-3-roothub-first.patch b/queue-4.5/xhci-resume-usb-3-roothub-first.patch new file mode 100644 index 00000000000..17217b51c98 --- /dev/null +++ b/queue-4.5/xhci-resume-usb-3-roothub-first.patch @@ -0,0 +1,48 @@ +From 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Fri, 8 Apr 2016 16:25:06 +0300 +Subject: xhci: resume USB 3 roothub first + +From: Mathias Nyman + +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 +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + }