--- /dev/null
+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
--- /dev/null
+From f28c42c576b293b3a1daaed8ca2775ebc2fe5398 Mon Sep 17 00:00:00 2001
+From: Peter Chen <peter.chen@freescale.com>
+Date: Fri, 24 May 2013 14:29:20 +0800
+Subject: usb: dwc3: pci: PHY should be deleted later than dwc3 core
+
+From: Peter Chen <peter.chen@freescale.com>
+
+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 <peter.chen@freescale.com>
+Signed-off-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 Mon Sep 17 00:00:00 2001
+From: Bjørn Mork <bjorn@mork.no>
+Date: Thu, 6 Jun 2013 12:57:24 +0200
+Subject: USB: option: blacklist network interface on Huawei E1820
+
+From: Bjørn Mork <bjorn@mork.no>
+
+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 <graham.inggs@uct.ac.za>
+Signed-off-by: Bjørn Mork <bjorn@mork.no>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) },
--- /dev/null
+From 73228a0538a70ebc4547bd09dee8971360dc1d87 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dcbw@redhat.com>
+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 <dcbw@redhat.com>
+
+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 <dcbw@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 8a2f132a01c2dd4c3905fa560f92019761ed72b1 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 24 May 2013 12:01:51 +0200
+Subject: USB: serial: Add Option GTM681W to qcserial device table.
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1 upstream.
+
+The Option GTM681W uses a qualcomm chip and can be
+served by the qcserial device driver.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From 65694c5aaddfedd9da082e4e150cafc6b3fc8a6a Mon Sep 17 00:00:00 2001
+From: Matt Fleming <matt.fleming@intel.com>
+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 <matt.fleming@intel.com>
+
+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: [<c262be0f>] pcibios_add_device+0x2f/0x90
+ ...
+ Call Trace:
+ [<c2370c73>] pci_device_add+0xe3/0x130
+ [<c274640b>] pci_scan_single_device+0x8b/0xb0
+ [<c2370d08>] pci_scan_slot+0x48/0x100
+ [<c2371904>] pci_scan_child_bus+0x24/0xc0
+ [<c262a7b0>] pci_acpi_scan_root+0x2c0/0x490
+ [<c23b7203>] 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 <jani.nikula@intel.com>
+Signed-off-by: Matt Fleming <matt.fleming@intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Matthew Garrett <mjg59@srcf.ucam.org>
+Cc: Seth Forshee <seth.forshee@canonical.com>
+Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 77df9e0b799b03e1d5d9c68062709af5f637e834 Mon Sep 17 00:00:00 2001
+From: Tony Camuso <tcamuso@redhat.com>
+Date: Thu, 21 Feb 2013 16:11:27 -0500
+Subject: xhci - correct comp_mode_recovery_timer on return from hibernate
+
+From: Tony Camuso <tcamuso@redhat.com>
+
+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 <tcamuso@redhat.com>
+Tested-by: Tony Camuso <tcamuso@redhat.com>
+Acked-by: Don Zickus <dzickus@redhat.com>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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. */
--- /dev/null
+From c3897aa5386faba77e5bbdf94902a1658d3a5b11 Mon Sep 17 00:00:00 2001
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Date: Thu, 18 Apr 2013 10:02:03 -0700
+Subject: xhci: Disable D3cold for buggy TI redrivers.
+
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+
+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 <sarah.a.sharp@linux.intel.com>
+Cc: Huang Ying <ying.huang@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From 88696ae432ce7321540ac53d9caab3de9118b094 Mon Sep 17 00:00:00 2001
+From: Vladimir Murzin <murzin.v@gmail.com>
+Date: Tue, 9 Apr 2013 22:33:31 +0400
+Subject: xhci: fix list access before init
+
+From: Vladimir Murzin <murzin.v@gmail.com>
+
+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 <dserrg@gmail.com>
+Tested-by: Sergey Dyasly <dserrg@gmail.com>
+Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 331de00a64e5027365145bdf51da27b9ce15dfd5 Mon Sep 17 00:00:00 2001
+From: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
+Date: Thu, 4 Apr 2013 10:32:13 -0700
+Subject: xhci-mem: init list heads at the beginning of init
+
+From: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
+
+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 <sergio.a.aguirre.rodriguez@intel.com>
+Acked-by: David Cohen <david.a.cohen@intel.com>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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).
projects / thirdparty / kernel / stable-queue.git / commitdiff
