From: Greg Kroah-Hartman Date: Fri, 7 Jun 2013 22:30:16 +0000 (-0700) Subject: 3.9-stable patches X-Git-Tag: v3.0.82~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d2c1438e67c5decda5e3ace359e3e57f1fc05479;p=thirdparty%2Fkernel%2Fstable-queue.git 3.9-stable patches added patches: usb-dwc3-pci-phy-should-be-deleted-later-than-dwc3-core.patch usb-option-blacklist-network-interface-on-huawei-e1820.patch usb-option-zte_ev-move-most-zte-cdma-devices-to-zte_ev.patch usb-serial-add-option-gtm681w-to-qcserial-device-table.patch x86-pci-map-pci-setup-data-with-ioremap-so-it-can-be-in-highmem.patch xhci-correct-comp_mode_recovery_timer-on-return-from-hibernate.patch xhci-disable-d3cold-for-buggy-ti-redrivers.patch xhci-fix-list-access-before-init.patch xhci-mem-init-list-heads-at-the-beginning-of-init.patch --- diff --git a/queue-3.9/series b/queue-3.9/series new file mode 100644 index 00000000000..f4ef90a3165 --- /dev/null +++ b/queue-3.9/series @@ -0,0 +1,9 @@ +usb-serial-add-option-gtm681w-to-qcserial-device-table.patch +usb-option-blacklist-network-interface-on-huawei-e1820.patch +usb-option-zte_ev-move-most-zte-cdma-devices-to-zte_ev.patch +usb-dwc3-pci-phy-should-be-deleted-later-than-dwc3-core.patch +xhci-correct-comp_mode_recovery_timer-on-return-from-hibernate.patch +xhci-mem-init-list-heads-at-the-beginning-of-init.patch +xhci-fix-list-access-before-init.patch +xhci-disable-d3cold-for-buggy-ti-redrivers.patch +x86-pci-map-pci-setup-data-with-ioremap-so-it-can-be-in-highmem.patch diff --git a/queue-3.9/usb-dwc3-pci-phy-should-be-deleted-later-than-dwc3-core.patch b/queue-3.9/usb-dwc3-pci-phy-should-be-deleted-later-than-dwc3-core.patch new file mode 100644 index 00000000000..0ab18cea233 --- /dev/null +++ b/queue-3.9/usb-dwc3-pci-phy-should-be-deleted-later-than-dwc3-core.patch @@ -0,0 +1,40 @@ +From f28c42c576b293b3a1daaed8ca2775ebc2fe5398 Mon Sep 17 00:00:00 2001 +From: Peter Chen +Date: Fri, 24 May 2013 14:29:20 +0800 +Subject: usb: dwc3: pci: PHY should be deleted later than dwc3 core + +From: Peter Chen + +commit f28c42c576b293b3a1daaed8ca2775ebc2fe5398 upstream. + +If the glue layer is removed first (core layer later), +it deletes the phy device first, then the core device. +But at core's removal, it still uses PHY's resources, it may +cause kernel's oops. It is much like the problem +Paul Zimmerman reported at: +http://marc.info/?l=linux-usb&m=136547502011472&w=2. + +Besides, it is reasonable the PHY is deleted at last as +the controller is the PHY's user. + +Signed-off-by: Peter Chen +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/dwc3/dwc3-pci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/dwc3/dwc3-pci.c ++++ b/drivers/usb/dwc3/dwc3-pci.c +@@ -196,9 +196,9 @@ static void dwc3_pci_remove(struct pci_d + { + struct dwc3_pci *glue = pci_get_drvdata(pci); + ++ platform_device_unregister(glue->dwc3); + platform_device_unregister(glue->usb2_phy); + platform_device_unregister(glue->usb3_phy); +- platform_device_unregister(glue->dwc3); + pci_set_drvdata(pci, NULL); + pci_disable_device(pci); + } diff --git a/queue-3.9/usb-option-blacklist-network-interface-on-huawei-e1820.patch b/queue-3.9/usb-option-blacklist-network-interface-on-huawei-e1820.patch new file mode 100644 index 00000000000..1ffa0c801bb --- /dev/null +++ b/queue-3.9/usb-option-blacklist-network-interface-on-huawei-e1820.patch @@ -0,0 +1,32 @@ +From b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 Mon Sep 17 00:00:00 2001 +From: Bjørn Mork +Date: Thu, 6 Jun 2013 12:57:24 +0200 +Subject: USB: option: blacklist network interface on Huawei E1820 + +From: Bjørn Mork + +commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream. + +The mode used by Windows for the Huawei E1820 will use the +same ff/ff/ff class codes for both serial and network +functions. + +Reported-by: Graham Inggs +Signed-off-by: Bjørn Mork +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/serial/option.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/usb/serial/option.c ++++ b/drivers/usb/serial/option.c +@@ -593,6 +593,8 @@ static const struct usb_device_id option + .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3765, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, ++ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x14ac, 0xff, 0xff, 0xff), /* Huawei E1820 */ ++ .driver_info = (kernel_ulong_t) &net_intf1_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0xff, 0xff) }, diff --git a/queue-3.9/usb-option-zte_ev-move-most-zte-cdma-devices-to-zte_ev.patch b/queue-3.9/usb-option-zte_ev-move-most-zte-cdma-devices-to-zte_ev.patch new file mode 100644 index 00000000000..f9664ec4df3 --- /dev/null +++ b/queue-3.9/usb-option-zte_ev-move-most-zte-cdma-devices-to-zte_ev.patch @@ -0,0 +1,121 @@ +From 73228a0538a70ebc4547bd09dee8971360dc1d87 Mon Sep 17 00:00:00 2001 +From: Dan Williams +Date: Wed, 5 Jun 2013 15:26:27 -0500 +Subject: USB: option,zte_ev: move most ZTE CDMA devices to zte_ev + +From: Dan Williams + +commit 73228a0538a70ebc4547bd09dee8971360dc1d87 upstream. + +Per some ZTE Linux drivers I found for the AC2716, the following patch +moves most ZTE CDMA devices from option to zte_ev. The blacklist stuff +that option does is not required with zte_ev, because it doesn't +implement any of the send_setup hooks which the blacklist suppressed. + +I did not move the 2718 over because I could not find any ZTE Linux +drivers for that device, nor even any Windows drivers. + +Signed-off-by: Dan Williams +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/serial/option.c | 24 +----------------------- + drivers/usb/serial/zte_ev.c | 24 +++++++++++++++++++++--- + 2 files changed, 22 insertions(+), 26 deletions(-) + +--- a/drivers/usb/serial/option.c ++++ b/drivers/usb/serial/option.c +@@ -250,13 +250,7 @@ static void option_instat_callback(struc + #define ZTE_PRODUCT_MF622 0x0001 + #define ZTE_PRODUCT_MF628 0x0015 + #define ZTE_PRODUCT_MF626 0x0031 +-#define ZTE_PRODUCT_CDMA_TECH 0xfffe +-#define ZTE_PRODUCT_AC8710 0xfff1 +-#define ZTE_PRODUCT_AC2726 0xfff5 +-#define ZTE_PRODUCT_AC8710T 0xffff + #define ZTE_PRODUCT_MC2718 0xffe8 +-#define ZTE_PRODUCT_AD3812 0xffeb +-#define ZTE_PRODUCT_MC2716 0xffed + + #define BENQ_VENDOR_ID 0x04a5 + #define BENQ_PRODUCT_H10 0x4068 +@@ -495,18 +489,10 @@ static const struct option_blacklist_inf + .reserved = BIT(4), + }; + +-static const struct option_blacklist_info zte_ad3812_z_blacklist = { +- .sendsetup = BIT(0) | BIT(1) | BIT(2), +-}; +- + static const struct option_blacklist_info zte_mc2718_z_blacklist = { + .sendsetup = BIT(1) | BIT(2) | BIT(3) | BIT(4), + }; + +-static const struct option_blacklist_info zte_mc2716_z_blacklist = { +- .sendsetup = BIT(1) | BIT(2) | BIT(3), +-}; +- + static const struct option_blacklist_info huawei_cdc12_blacklist = { + .reserved = BIT(1) | BIT(2), + }; +@@ -799,7 +785,6 @@ static const struct usb_device_id option + { USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_1012, 0xff) }, + { USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC650) }, + { USB_DEVICE(KYOCERA_VENDOR_ID, KYOCERA_PRODUCT_KPC680) }, +- { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6000)}, /* ZTE AC8700 */ + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ + { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6280) }, /* BP3-USB & BP3-EXT HSDPA */ +@@ -1201,16 +1186,9 @@ static const struct usb_device_id option + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0178, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&net_intf3_blacklist }, + +- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 0xff, 0xff, 0xff) }, +- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710, 0xff, 0xff, 0xff) }, +- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726, 0xff, 0xff, 0xff) }, +- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710T, 0xff, 0xff, 0xff) }, ++ /* NOTE: most ZTE CDMA devices should be driven by zte_ev, not option */ + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&zte_mc2718_z_blacklist }, +- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AD3812, 0xff, 0xff, 0xff), +- .driver_info = (kernel_ulong_t)&zte_ad3812_z_blacklist }, +- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716, 0xff, 0xff, 0xff), +- .driver_info = (kernel_ulong_t)&zte_mc2716_z_blacklist }, + { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) }, + { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) }, + { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) }, +--- a/drivers/usb/serial/zte_ev.c ++++ b/drivers/usb/serial/zte_ev.c +@@ -279,11 +279,29 @@ static void zte_ev_usb_serial_close(stru + } + + static const struct usb_device_id id_table[] = { +- { USB_DEVICE(0x19d2, 0xffff) }, /* AC8700 */ +- { USB_DEVICE(0x19d2, 0xfffe) }, +- { USB_DEVICE(0x19d2, 0xfffd) }, /* MG880 */ ++ /* AC8710, AC8710T */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xffff, 0xff, 0xff, 0xff) }, ++ /* AC8700 */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xfffe, 0xff, 0xff, 0xff) }, ++ /* MG880 */ ++ { USB_DEVICE(0x19d2, 0xfffd) }, ++ { USB_DEVICE(0x19d2, 0xfffc) }, ++ { USB_DEVICE(0x19d2, 0xfffb) }, ++ /* AC2726, AC8710_V3 */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xfff1, 0xff, 0xff, 0xff) }, ++ { USB_DEVICE(0x19d2, 0xfff6) }, ++ { USB_DEVICE(0x19d2, 0xfff7) }, ++ { USB_DEVICE(0x19d2, 0xfff8) }, ++ { USB_DEVICE(0x19d2, 0xfff9) }, ++ { USB_DEVICE(0x19d2, 0xffee) }, ++ /* AC2716, MC2716 */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xffed, 0xff, 0xff, 0xff) }, ++ /* AD3812 */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xffeb, 0xff, 0xff, 0xff) }, ++ { USB_DEVICE(0x19d2, 0xffec) }, + { USB_DEVICE(0x05C6, 0x3197) }, + { USB_DEVICE(0x05C6, 0x6000) }, ++ { USB_DEVICE(0x05C6, 0x9008) }, + { }, + }; + MODULE_DEVICE_TABLE(usb, id_table); diff --git a/queue-3.9/usb-serial-add-option-gtm681w-to-qcserial-device-table.patch b/queue-3.9/usb-serial-add-option-gtm681w-to-qcserial-device-table.patch new file mode 100644 index 00000000000..d9ff94c464b --- /dev/null +++ b/queue-3.9/usb-serial-add-option-gtm681w-to-qcserial-device-table.patch @@ -0,0 +1,29 @@ +From 8a2f132a01c2dd4c3905fa560f92019761ed72b1 Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Fri, 24 May 2013 12:01:51 +0200 +Subject: USB: serial: Add Option GTM681W to qcserial device table. + +From: Richard Weinberger + +commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1 upstream. + +The Option GTM681W uses a qualcomm chip and can be +served by the qcserial device driver. + +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/serial/qcserial.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/serial/qcserial.c ++++ b/drivers/usb/serial/qcserial.c +@@ -118,6 +118,7 @@ static const struct usb_device_id id_tab + {USB_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */ + {USB_DEVICE(0x12D1, 0x14F0)}, /* Sony Gobi 3000 QDL */ + {USB_DEVICE(0x12D1, 0x14F1)}, /* Sony Gobi 3000 Composite */ ++ {USB_DEVICE(0x0AF0, 0x8120)}, /* Option GTM681W */ + + /* non Gobi Qualcomm serial devices */ + {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 0)}, /* Sierra Wireless MC7700 Device Management */ diff --git a/queue-3.9/x86-pci-map-pci-setup-data-with-ioremap-so-it-can-be-in-highmem.patch b/queue-3.9/x86-pci-map-pci-setup-data-with-ioremap-so-it-can-be-in-highmem.patch new file mode 100644 index 00000000000..cd40309810b --- /dev/null +++ b/queue-3.9/x86-pci-map-pci-setup-data-with-ioremap-so-it-can-be-in-highmem.patch @@ -0,0 +1,70 @@ +From 65694c5aaddfedd9da082e4e150cafc6b3fc8a6a Mon Sep 17 00:00:00 2001 +From: Matt Fleming +Date: Wed, 5 Jun 2013 15:15:41 +0100 +Subject: x86/PCI: Map PCI setup data with ioremap() so it can be in highmem + +From: Matt Fleming + +commit 65694c5aaddfedd9da082e4e150cafc6b3fc8a6a upstream. + +f9a37be0f0 ("x86: Use PCI setup data") added support for using PCI ROM +images from setup_data. This used phys_to_virt(), which is not valid for +highmem addresses, and can cause a crash when booting a 32-bit kernel via +the EFI boot stub. + +pcibios_add_device() assumes that the physical addresses stored in +setup_data are accessible via the direct kernel mapping, and that calling +phys_to_virt() is valid. This isn't guaranteed to be true on x86 where the +direct mapping range is much smaller than on x86-64. + +Calling phys_to_virt() on a highmem address results in the following: + + BUG: unable to handle kernel paging request at 39a3c198 + IP: [] pcibios_add_device+0x2f/0x90 + ... + Call Trace: + [] pci_device_add+0xe3/0x130 + [] pci_scan_single_device+0x8b/0xb0 + [] pci_scan_slot+0x48/0x100 + [] pci_scan_child_bus+0x24/0xc0 + [] pci_acpi_scan_root+0x2c0/0x490 + [] acpi_pci_root_add+0x312/0x42f + ... + +The solution is to use ioremap() instead of phys_to_virt() to map the +setup data into the kernel address space. + +[bhelgaas: changelog] +Tested-by: Jani Nikula +Signed-off-by: Matt Fleming +Signed-off-by: Bjorn Helgaas +Cc: Matthew Garrett +Cc: Seth Forshee +Cc: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/pci/common.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/arch/x86/pci/common.c ++++ b/arch/x86/pci/common.c +@@ -617,7 +617,9 @@ int pcibios_add_device(struct pci_dev *d + + pa_data = boot_params.hdr.setup_data; + while (pa_data) { +- data = phys_to_virt(pa_data); ++ data = ioremap(pa_data, sizeof(*rom)); ++ if (!data) ++ return -ENOMEM; + + if (data->type == SETUP_PCI) { + rom = (struct pci_setup_rom *)data; +@@ -634,6 +636,7 @@ int pcibios_add_device(struct pci_dev *d + } + } + pa_data = data->next; ++ iounmap(data); + } + return 0; + } diff --git a/queue-3.9/xhci-correct-comp_mode_recovery_timer-on-return-from-hibernate.patch b/queue-3.9/xhci-correct-comp_mode_recovery_timer-on-return-from-hibernate.patch new file mode 100644 index 00000000000..0801d7f5050 --- /dev/null +++ b/queue-3.9/xhci-correct-comp_mode_recovery_timer-on-return-from-hibernate.patch @@ -0,0 +1,104 @@ +From 77df9e0b799b03e1d5d9c68062709af5f637e834 Mon Sep 17 00:00:00 2001 +From: Tony Camuso +Date: Thu, 21 Feb 2013 16:11:27 -0500 +Subject: xhci - correct comp_mode_recovery_timer on return from hibernate + +From: Tony Camuso + +commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream. + +Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP +Hardware) was a workaround for systems using the SN65LVPE502CP, +controller, but it introduced a bug in resume from hibernate. + +The fix created a timer, comp_mode_recovery_timer, which is deleted from +a timer list when xhci_suspend() is called. However, the hibernate image, +including the timer list containing the comp_mode_recovery_timer, had +already been saved before the timer was deleted. + +Upon resume from hibernate, the list containing the comp_mode_recovery_timer +is restored from the image saved to disk, and xhci_resume(), assuming that +the timer had been deleted by xhci_suspend(), makes a call to +compliance_mode_recoery_timer_init(), which creates a new instance of the +comp_mode_recovery_timer and attempts to place it into the same list in which +it is already active, thus corrupting the list during the list_add() call. + +At this point, a call trace is emitted indicating the list corruption. +Soon afterward, the system locks up, the watchdog times out, and the +ensuing NMI crashes the system. + +The problem did not occur when resuming from suspend. In suspend, the +image in RAM remains exactly as it was when xhci_suspend() deleted the +comp_mode_recovery_timer, so there is no problem when xhci_resume() +creates a new instance of this timer and places it in the still empty +list. + +This patch avoids the problem by deleting the timer in xhci_resume() +when resuming from hibernate. Now xhci_resume() can safely make the +call to create a new instance of this timer, whether returning from +suspend or hibernate. + +Thanks to Alan Stern for his help with understanding the problem. + +[Sarah reworked this patch to cover the case where the xHCI restore +register operation fails, and (temp & STS_SRE) is true (and we re-init +the host, including re-init for the compliance mode), but hibernate is +false. The original patch would have caused list corruption in this +case.] + +This patch should be backported to kernels as old as 3.2, that +contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: +xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" + +Signed-off-by: Tony Camuso +Tested-by: Tony Camuso +Acked-by: Don Zickus +Signed-off-by: Sarah Sharp +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -952,6 +952,7 @@ int xhci_resume(struct xhci_hcd *xhci, b + struct usb_hcd *hcd = xhci_to_hcd(xhci); + struct usb_hcd *secondary_hcd; + int retval = 0; ++ bool comp_timer_running = false; + + /* Wait a bit if either of the roothubs need to settle from the + * transition into bus suspend. +@@ -989,6 +990,13 @@ int xhci_resume(struct xhci_hcd *xhci, b + + /* If restore operation fails, re-initialize the HC during resume */ + if ((temp & STS_SRE) || hibernated) { ++ ++ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && ++ !(xhci_all_ports_seen_u0(xhci))) { ++ del_timer_sync(&xhci->comp_mode_recovery_timer); ++ xhci_dbg(xhci, "Compliance Mode Recovery Timer deleted!\n"); ++ } ++ + /* Let the USB core know _both_ roothubs lost power. */ + usb_root_hub_lost_power(xhci->main_hcd->self.root_hub); + usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub); +@@ -1031,6 +1039,8 @@ int xhci_resume(struct xhci_hcd *xhci, b + retval = xhci_init(hcd->primary_hcd); + if (retval) + return retval; ++ comp_timer_running = true; ++ + xhci_dbg(xhci, "Start the primary HCD\n"); + retval = xhci_run(hcd->primary_hcd); + if (!retval) { +@@ -1072,7 +1082,7 @@ int xhci_resume(struct xhci_hcd *xhci, b + * to suffer the Compliance Mode issue again. It doesn't matter if + * ports have entered previously to U0 before system's suspension. + */ +- if (xhci->quirks & XHCI_COMP_MODE_QUIRK) ++ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && !comp_timer_running) + compliance_mode_recovery_timer_init(xhci); + + /* Re-enable port polling. */ diff --git a/queue-3.9/xhci-disable-d3cold-for-buggy-ti-redrivers.patch b/queue-3.9/xhci-disable-d3cold-for-buggy-ti-redrivers.patch new file mode 100644 index 00000000000..0f9138cb4fa --- /dev/null +++ b/queue-3.9/xhci-disable-d3cold-for-buggy-ti-redrivers.patch @@ -0,0 +1,94 @@ +From c3897aa5386faba77e5bbdf94902a1658d3a5b11 Mon Sep 17 00:00:00 2001 +From: Sarah Sharp +Date: Thu, 18 Apr 2013 10:02:03 -0700 +Subject: xhci: Disable D3cold for buggy TI redrivers. + +From: Sarah Sharp + +commit c3897aa5386faba77e5bbdf94902a1658d3a5b11 upstream. + +Some xHCI hosts contain a "redriver" from TI that silently drops port +status connect changes if the port slips into Compliance Mode. If the +port slips into compliance mode while the host is in D0, there will not +be a port status change event. If the port slips into compliance mode +while the host is in D3, the host will not send a PME. This includes +when the system is suspended (S3) or hibernated (S4). + +If this happens when the system is in S3/S4, there is nothing software +can do. Other port status change events that would normally cause the +host to wake the system from S3/S4 may also be lost. This includes +remote wakeup, disconnects and connects on other ports, and overrcurrent +events. A decision was made to _NOT_ disable system suspend/hibernate +on these systems, since users are unlikely to enable wakeup from S3/S4 +for the xHCI host. + +Software can deal with this issue when the system is in S0. A work +around was put in to poll the port status registers for Compliance Mode. +The xHCI driver will continue to poll the registers while the host is +runtime suspended. Unfortunately, that means we can't allow the PCI +device to go into D3cold, because power will be removed from the host, +and the config space will read as all Fs. + +Disable D3cold in the xHCI PCI runtime suspend function. + +This patch should be backported to kernels as old as 3.2, that +contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: +xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" + +Signed-off-by: Sarah Sharp +Cc: Huang Ying +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci-pci.c | 8 ++++++++ + drivers/usb/host/xhci.c | 4 ++-- + drivers/usb/host/xhci.h | 3 +++ + 3 files changed, 13 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -221,6 +221,14 @@ static void xhci_pci_remove(struct pci_d + static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup) + { + struct xhci_hcd *xhci = hcd_to_xhci(hcd); ++ struct pci_dev *pdev = to_pci_dev(hcd->self.controller); ++ ++ /* ++ * Systems with the TI redriver that loses port status change events ++ * need to have the registers polled during D3, so avoid D3cold. ++ */ ++ if (xhci_compliance_mode_recovery_timer_quirk_check()) ++ pdev->no_d3cold = true; + + return xhci_suspend(xhci); + } +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -466,7 +466,7 @@ static void compliance_mode_recovery_tim + * Systems: + * Vendor: Hewlett-Packard -> System Models: Z420, Z620 and Z820 + */ +-static bool compliance_mode_recovery_timer_quirk_check(void) ++bool xhci_compliance_mode_recovery_timer_quirk_check(void) + { + const char *dmi_product_name, *dmi_sys_vendor; + +@@ -517,7 +517,7 @@ int xhci_init(struct usb_hcd *hcd) + xhci_dbg(xhci, "Finished xhci_init\n"); + + /* Initializing Compliance Mode Recovery Data If Needed */ +- if (compliance_mode_recovery_timer_quirk_check()) { ++ if (xhci_compliance_mode_recovery_timer_quirk_check()) { + xhci->quirks |= XHCI_COMP_MODE_QUIRK; + compliance_mode_recovery_timer_init(xhci); + } +--- a/drivers/usb/host/xhci.h ++++ b/drivers/usb/host/xhci.h +@@ -1853,4 +1853,7 @@ struct xhci_input_control_ctx *xhci_get_ + struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx); + struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx, unsigned int ep_index); + ++/* xHCI quirks */ ++bool xhci_compliance_mode_recovery_timer_quirk_check(void); ++ + #endif /* __LINUX_XHCI_HCD_H */ diff --git a/queue-3.9/xhci-fix-list-access-before-init.patch b/queue-3.9/xhci-fix-list-access-before-init.patch new file mode 100644 index 00000000000..e7e6b57c1cf --- /dev/null +++ b/queue-3.9/xhci-fix-list-access-before-init.patch @@ -0,0 +1,49 @@ +From 88696ae432ce7321540ac53d9caab3de9118b094 Mon Sep 17 00:00:00 2001 +From: Vladimir Murzin +Date: Tue, 9 Apr 2013 22:33:31 +0400 +Subject: xhci: fix list access before init + +From: Vladimir Murzin + +commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream. + +If for whatever reason we fall into fail path in xhci_mem_init() +before bw table gets initialized we may access the uninitialized lists +in xhci_mem_cleanup(). + +Check for bw table before traversing lists in cleanup routine. + +This patch should be backported to kernels as old as 3.2, that contain +the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store +information about roothubs and TTs." + +Reported-by: Sergey Dyasly +Tested-by: Sergey Dyasly +Signed-off-by: Vladimir Murzin +Signed-off-by: Sarah Sharp +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci-mem.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/usb/host/xhci-mem.c ++++ b/drivers/usb/host/xhci-mem.c +@@ -1827,6 +1827,9 @@ void xhci_mem_cleanup(struct xhci_hcd *x + } + spin_unlock_irqrestore(&xhci->lock, flags); + ++ if (!xhci->rh_bw) ++ goto no_bw; ++ + num_ports = HCS_MAX_PORTS(xhci->hcs_params1); + for (i = 0; i < num_ports; i++) { + struct xhci_interval_bw_table *bwt = &xhci->rh_bw[i].bw_table; +@@ -1845,6 +1848,7 @@ void xhci_mem_cleanup(struct xhci_hcd *x + } + } + ++no_bw: + xhci->num_usb2_ports = 0; + xhci->num_usb3_ports = 0; + xhci->num_active_eps = 0; diff --git a/queue-3.9/xhci-mem-init-list-heads-at-the-beginning-of-init.patch b/queue-3.9/xhci-mem-init-list-heads-at-the-beginning-of-init.patch new file mode 100644 index 00000000000..5accfffe24e --- /dev/null +++ b/queue-3.9/xhci-mem-init-list-heads-at-the-beginning-of-init.patch @@ -0,0 +1,60 @@ +From 331de00a64e5027365145bdf51da27b9ce15dfd5 Mon Sep 17 00:00:00 2001 +From: Sergio Aguirre +Date: Thu, 4 Apr 2013 10:32:13 -0700 +Subject: xhci-mem: init list heads at the beginning of init + +From: Sergio Aguirre + +commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream. + +It is possible that we fail on xhci_mem_init, just before doing +the INIT_LIST_HEAD, and calling xhci_mem_cleanup. + +Problem is that, the list_for_each_entry_safe macro, assumes +list heads are initialized (not NULL), and dereferences their 'next' +pointer, causing a kernel panic if this is not yet initialized. + +Let's protect from that by moving inits to the beginning. + +This patch should be backported to kernels as old as 3.2, that +contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test +USB2 software LPM". + +Signed-off-by: Sergio Aguirre +Acked-by: David Cohen +Signed-off-by: Sarah Sharp +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci-mem.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci-mem.c ++++ b/drivers/usb/host/xhci-mem.c +@@ -2256,6 +2256,9 @@ int xhci_mem_init(struct xhci_hcd *xhci, + u32 page_size, temp; + int i; + ++ INIT_LIST_HEAD(&xhci->lpm_failed_devs); ++ INIT_LIST_HEAD(&xhci->cancel_cmd_list); ++ + page_size = xhci_readl(xhci, &xhci->op_regs->page_size); + xhci_dbg(xhci, "Supported page size register = 0x%x\n", page_size); + for (i = 0; i < 16; i++) { +@@ -2334,7 +2337,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, + xhci->cmd_ring = xhci_ring_alloc(xhci, 1, 1, TYPE_COMMAND, flags); + if (!xhci->cmd_ring) + goto fail; +- INIT_LIST_HEAD(&xhci->cancel_cmd_list); + xhci_dbg(xhci, "Allocated command ring at %p\n", xhci->cmd_ring); + xhci_dbg(xhci, "First segment DMA is 0x%llx\n", + (unsigned long long)xhci->cmd_ring->first_seg->dma); +@@ -2445,8 +2447,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, + if (xhci_setup_port_arrays(xhci, flags)) + goto fail; + +- INIT_LIST_HEAD(&xhci->lpm_failed_devs); +- + /* Enable USB 3.0 device notifications for function remote wake, which + * is necessary for allowing USB 3.0 devices to do remote wakeup from + * U3 (device suspend).