usb-chipidea-msm-initialize-phy-on-reset-event.patch
usb-ftdi_sio-add-support-for-ge-healthcare-nemo-tracker-device.patch
usb-ftdi_sio-add-support-for-novitus-bono-e-thermal-printer.patch
+usb-zte_ev-fix-removed-pids.patch
+uwb-init-beacon-cache-entry-before-registering-uwb-device.patch
+usb-host-xhci-fix-compliance-mode-workaround.patch
+xhci-fix-null-pointer-dereference-if-xhci-initialization-fails.patch
+xhci-fix-oops-when-xhci-resumes-from-hibernate-with-hw-lpm-capable-devices.patch
+usb-hub-take-hub-hdev-reference-when-processing-from-eventlist.patch
+storage-add-single-lun-quirk-for-jaz-usb-adapter.patch
+usb-storage-add-quirk-for-adaptec-usbconnect-2000-usb-to-scsi-adapter.patch
+usb-storage-add-quirk-for-ariston-technologies-iconnect-usb-to-scsi-adapter.patch
+usb-storage-add-quirks-for-entrega-xircom-usb-to-scsi-converters.patch
+usb-ehci-unlink-qhs-even-after-the-controller-has-stopped.patch
--- /dev/null
+From c66f1c62e85927357e7b3f4c701614dcb5c498a2 Mon Sep 17 00:00:00 2001
+From: Mark <markk@clara.co.uk>
+Date: Thu, 11 Sep 2014 13:15:45 +0100
+Subject: storage: Add single-LUN quirk for Jaz USB Adapter
+
+From: Mark <markk@clara.co.uk>
+
+commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream.
+
+The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware
+seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/
+SCM chip set. However its firmware restricts it to only work with Jaz
+drives.
+
+On connecting the cable a message like this appears four times in the log:
+ reset full speed USB device number 4 using uhci_hcd
+
+That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it.
+
+Signed-off-by: Mark Knibbs <markk@clara.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_devs.h | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -741,6 +741,12 @@ UNUSUAL_DEV( 0x059b, 0x0001, 0x0100, 0x
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_SINGLE_LUN ),
+
++UNUSUAL_DEV( 0x059b, 0x0040, 0x0100, 0x0100,
++ "Iomega",
++ "Jaz USB Adapter",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_SINGLE_LUN ),
++
+ /* Reported by <Hendryk.Pfeiffer@gmx.de> */
+ UNUSUAL_DEV( 0x059f, 0x0643, 0x0000, 0x0000,
+ "LaCie",
--- /dev/null
+From 7312b5ddd47fee2356baa78c5516ef8e04eed452 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Wed, 17 Sep 2014 11:23:54 -0400
+Subject: USB: EHCI: unlink QHs even after the controller has stopped
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 7312b5ddd47fee2356baa78c5516ef8e04eed452 upstream.
+
+Old code in ehci-hcd tries to expedite disabling endpoints after the
+controller has stopped, by destroying the endpoint's associated QH
+without first unlinking the QH. This was necessary back when the
+driver wasn't so careful about keeping track of the controller's
+state.
+
+But now we are careful about it, and the driver knows that when the
+controller isn't running, no unlinking delay is needed. Furthermore,
+skipping the unlink step will trigger a BUG() in qh_destroy() when the
+preceding QH is released, because the link pointer will be non-NULL.
+
+Removing the lines that skip the unlinking step and go directly to
+QH_STATE_IDLE fixes the problem.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
+Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/ehci-hcd.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/usb/host/ehci-hcd.c
++++ b/drivers/usb/host/ehci-hcd.c
+@@ -965,8 +965,6 @@ rescan:
+ }
+
+ qh->exception = 1;
+- if (ehci->rh_state < EHCI_RH_RUNNING)
+- qh->qh_state = QH_STATE_IDLE;
+ switch (qh->qh_state) {
+ case QH_STATE_LINKED:
+ WARN_ON(!list_empty(&qh->qtd_list));
--- /dev/null
+From 96908589a8b2584b1185f834d365f5cc360e8226 Mon Sep 17 00:00:00 2001
+From: Felipe Balbi <balbi@ti.com>
+Date: Wed, 27 Aug 2014 16:38:04 -0500
+Subject: usb: host: xhci: fix compliance mode workaround
+
+From: Felipe Balbi <balbi@ti.com>
+
+commit 96908589a8b2584b1185f834d365f5cc360e8226 upstream.
+
+Commit 71c731a (usb: host: xhci: Fix Compliance Mode
+on SN65LVP3502CP Hardware) implemented a workaround
+for a known issue with Texas Instruments' USB 3.0
+redriver IC but it left a condition where any xHCI
+host would be taken out of reset if port was placed
+in compliance mode and there was no device connected
+to the port.
+
+That condition would trigger a fake connection to a
+non-existent device so that usbcore would trigger a
+warm reset of the port, thus taking the link out of
+reset.
+
+This has the side-effect of preventing any xHCI host
+connected to a Linux machine from starting and running
+the USB 3.0 Electrical Compliance Suite because the
+port will mysteriously taken out of compliance mode
+and, thus, xHCI won't step through the necessary
+compliance patterns for link validation.
+
+This patch fixes the issue by just adding a missing
+check for XHCI_COMP_MODE_QUIRK inside
+xhci_hub_report_usb3_link_state() when PORT_CAS isn't
+set.
+
+This patch should be backported to all kernels containing
+commit 71c731a.
+
+Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware)
+Cc: Alexis R. Cortes <alexis.cortes@ti.com>
+Signed-off-by: Felipe Balbi <balbi@ti.com>
+Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -470,7 +470,8 @@ static void xhci_hub_report_usb2_link_st
+ }
+
+ /* Updates Link Status for super Speed port */
+-static void xhci_hub_report_usb3_link_state(u32 *status, u32 status_reg)
++static void xhci_hub_report_usb3_link_state(struct xhci_hcd *xhci,
++ u32 *status, u32 status_reg)
+ {
+ u32 pls = status_reg & PORT_PLS_MASK;
+
+@@ -509,7 +510,8 @@ static void xhci_hub_report_usb3_link_st
+ * in which sometimes the port enters compliance mode
+ * caused by a delay on the host-device negotiation.
+ */
+- if (pls == USB_SS_PORT_LS_COMP_MOD)
++ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
++ (pls == USB_SS_PORT_LS_COMP_MOD))
+ pls |= USB_PORT_STAT_CONNECTION;
+ }
+
+@@ -668,7 +670,7 @@ static u32 xhci_get_port_status(struct u
+ }
+ /* Update Port Link State */
+ if (hcd->speed == HCD_USB3) {
+- xhci_hub_report_usb3_link_state(&status, raw_port_status);
++ xhci_hub_report_usb3_link_state(xhci, &status, raw_port_status);
+ /*
+ * Verify if all USB3 Ports Have entered U0 already.
+ * Delete Compliance Mode Timer if so.
--- /dev/null
+From c605f3cdff53a743f6d875b76956b239deca1272 Mon Sep 17 00:00:00 2001
+From: Joe Lawrence <joe.lawrence@stratus.com>
+Date: Wed, 10 Sep 2014 15:07:50 -0400
+Subject: usb: hub: take hub->hdev reference when processing from eventlist
+
+From: Joe Lawrence <joe.lawrence@stratus.com>
+
+commit c605f3cdff53a743f6d875b76956b239deca1272 upstream.
+
+During surprise device hotplug removal tests, it was observed that
+hub_events may try to call usb_lock_device on a device that has already
+been freed. Protect the usb_device by taking out a reference (under the
+hub_event_lock) when hub_events pulls it off the list, returning the
+reference after hub_events is finished using it.
+
+Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
+Suggested-by: David Bulkow <david.bulkow@stratus.com> for using kref
+Suggested-by: Alan Stern <stern@rowland.harvard.edu> for placement
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hub.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -4764,9 +4764,10 @@ static void hub_events(void)
+
+ hub = list_entry(tmp, struct usb_hub, event_list);
+ kref_get(&hub->kref);
++ hdev = hub->hdev;
++ usb_get_dev(hdev);
+ spin_unlock_irq(&hub_event_lock);
+
+- hdev = hub->hdev;
+ hub_dev = hub->intfdev;
+ intf = to_usb_interface(hub_dev);
+ dev_dbg(hub_dev, "state %d ports %d chg %04x evt %04x\n",
+@@ -4979,6 +4980,7 @@ static void hub_events(void)
+ usb_autopm_put_interface(intf);
+ loop_disconnected:
+ usb_unlock_device(hdev);
++ usb_put_dev(hdev);
+ kref_put(&hub->kref, hub_release);
+
+ } /* end while (1) */
--- /dev/null
+From 67d365a57a51fb9dece6a5ceb504aa381cae1e5b Mon Sep 17 00:00:00 2001
+From: Mark <markk@clara.co.uk>
+Date: Tue, 16 Sep 2014 16:22:50 +0100
+Subject: USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter
+
+From: Mark <markk@clara.co.uk>
+
+commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream.
+
+The Adaptec USBConnect 2000 is another SCSI-USB converter which uses
+Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is
+required to use SCSI devices with ID other than 0.
+
+I don't have a USBConnect 2000, but based on the other entries for Shuttle/
+SCM-based converters this patch is very likely correct. I used 0x0000 and
+0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
+bcdDevice value the product uses.
+
+Signed-off-by: Mark Knibbs <markk@clara.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_devs.h | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -101,6 +101,12 @@ UNUSUAL_DEV( 0x03f0, 0x4002, 0x0001, 0x
+ "PhotoSmart R707",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_FIX_CAPACITY),
+
++UNUSUAL_DEV( 0x03f3, 0x0001, 0x0000, 0x9999,
++ "Adaptec",
++ "USBConnect 2000",
++ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
++ US_FL_SCM_MULT_TARG ),
++
+ /* Reported by Sebastian Kapfer <sebastian_kapfer@gmx.net>
+ * and Olaf Hering <olh@suse.de> (different bcd's, same vendor/product)
+ * for USB floppies that need the SINGLE_LUN enforcement.
--- /dev/null
+From b6a3ed677991558ce09046397a7c4d70530d15b3 Mon Sep 17 00:00:00 2001
+From: Mark <markk@clara.co.uk>
+Date: Tue, 16 Sep 2014 16:51:41 +0100
+Subject: USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter
+
+From: Mark <markk@clara.co.uk>
+
+commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream.
+
+Hi,
+
+The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g.
+iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM
+Microsystems chips. Only the connectors differ; both have the same USB ID.
+The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other
+than 0.
+
+I don't have one of these, but based on the other entries for Shuttle/
+SCM-based converters this patch is very likely correct. I used 0x0000 and
+0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
+bcdDevice value the products use.
+
+Signed-off-by: Mark Knibbs <markk@clara.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_devs.h | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -1979,6 +1979,12 @@ UNUSUAL_DEV( 0x177f, 0x0400, 0x0000, 0x
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BULK_IGNORE_TAG | US_FL_MAX_SECTORS_64 ),
+
++UNUSUAL_DEV( 0x1822, 0x0001, 0x0000, 0x9999,
++ "Ariston Technologies",
++ "iConnect USB to SCSI adapter",
++ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
++ US_FL_SCM_MULT_TARG ),
++
+ /* Reported by Hans de Goede <hdegoede@redhat.com>
+ * These Appotech controllers are found in Picture Frames, they provide a
+ * (buggy) emulation of a cdrom drive which contains the windows software
--- /dev/null
+From c80b4495c61636edc58fe1ce300f09f24db28e10 Mon Sep 17 00:00:00 2001
+From: Mark <markk@clara.co.uk>
+Date: Wed, 17 Sep 2014 19:15:43 +0100
+Subject: USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters
+
+From: Mark <markk@clara.co.uk>
+
+commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream.
+
+This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB-
+SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The
+US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI
+chain to be accessed. Without it only the (single) device with SCSI ID 0
+can be used.
+
+The standalone converter sold by Entrega had model number U1-SC25. Xircom
+acquired Entrega and re-branded the product line PortGear. The PortGear USB
+to SCSI Converter (model PGSCSI) is internally identical to the Entrega
+product, but later models may use a different USB ID. The Entrega-branded
+units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and
+Macintosh drivers also support 085A:0028.
+
+Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac
+(8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as
+a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may
+have initially used the same ID as the standalone U1-SC25 (1645:0007), but
+later production used 085A:0026.
+
+My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133
+probably also exist.
+
+This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows
+driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I
+couldn't find any mention of that actually existing in the wild; perhaps it
+was cancelled before release?
+
+Signed-off-by: Mark Knibbs <markk@clara.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_devs.h | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -1125,6 +1125,18 @@ UNUSUAL_DEV( 0x0851, 0x1543, 0x0200, 0x
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NOT_LOCKABLE),
+
++UNUSUAL_DEV( 0x085a, 0x0026, 0x0100, 0x0133,
++ "Xircom",
++ "PortGear USB-SCSI (Mac USB Dock)",
++ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
++ US_FL_SCM_MULT_TARG ),
++
++UNUSUAL_DEV( 0x085a, 0x0028, 0x0100, 0x0133,
++ "Xircom",
++ "PortGear USB to SCSI Converter",
++ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
++ US_FL_SCM_MULT_TARG ),
++
+ /* Submitted by Jan De Luyck <lkml@kcore.org> */
+ UNUSUAL_DEV( 0x08bd, 0x1100, 0x0000, 0x0000,
+ "CITIZEN",
+@@ -1957,6 +1969,14 @@ UNUSUAL_DEV( 0x152d, 0x2329, 0x0100, 0x
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_IGNORE_RESIDUE | US_FL_SANE_SENSE ),
+
++/* Entrega Technologies U1-SC25 (later Xircom PortGear PGSCSI)
++ * and Mac USB Dock USB-SCSI */
++UNUSUAL_DEV( 0x1645, 0x0007, 0x0100, 0x0133,
++ "Entrega Technologies",
++ "USB to SCSI Converter",
++ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
++ US_FL_SCM_MULT_TARG ),
++
+ /* Reported by Robert Schedel <r.schedel@yahoo.de>
+ * Note: this is a 'super top' device like the above 14cd/6600 device */
+ UNUSUAL_DEV( 0x1652, 0x6600, 0x0201, 0x0201,
--- /dev/null
+From 3096691011d01cef56b243a5e65431405c07d574 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 28 Aug 2014 12:46:54 +0200
+Subject: USB: zte_ev: fix removed PIDs
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 3096691011d01cef56b243a5e65431405c07d574 upstream.
+
+Add back some PIDs that were mistakingly remove when reverting commit
+73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to
+zte_ev"), which apparently did more than its commit message claimed in
+that it not only moved some PIDs from option to zte_ev but also added
+some new ones.
+
+Fixes: 63a901c06e3c ("Revert "USB: option,zte_ev: move most ZTE CDMA
+devices to zte_ev"")
+
+Reported-by: Lei Liu <lei35151@163.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/zte_ev.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/usb/serial/zte_ev.c
++++ b/drivers/usb/serial/zte_ev.c
+@@ -272,6 +272,14 @@ static void zte_ev_usb_serial_close(stru
+ }
+
+ static const struct usb_device_id id_table[] = {
++ { USB_DEVICE(0x19d2, 0xffec) },
++ { USB_DEVICE(0x19d2, 0xffee) },
++ { USB_DEVICE(0x19d2, 0xfff6) },
++ { USB_DEVICE(0x19d2, 0xfff7) },
++ { USB_DEVICE(0x19d2, 0xfff8) },
++ { USB_DEVICE(0x19d2, 0xfff9) },
++ { USB_DEVICE(0x19d2, 0xfffb) },
++ { USB_DEVICE(0x19d2, 0xfffc) },
+ /* MG880 */
+ { USB_DEVICE(0x19d2, 0xfffd) },
+ { },
--- /dev/null
+From 675f0ab2fe5a0f7325208e60b617a5f32b86d72c Mon Sep 17 00:00:00 2001
+From: Thomas Pugliese <thomas.pugliese@gmail.com>
+Date: Thu, 7 Aug 2014 15:45:35 -0500
+Subject: uwb: init beacon cache entry before registering uwb device
+
+From: Thomas Pugliese <thomas.pugliese@gmail.com>
+
+commit 675f0ab2fe5a0f7325208e60b617a5f32b86d72c upstream.
+
+Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in
+uwbd_dev_onair so that usermode will only see the device after it is
+properly initialized. This fixes a kernel panic that can occur if
+usermode tries to access the IEs sysfs attribute of a UWB device before
+the driver has had a chance to set the beacon cache entry.
+
+Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/uwb/lc-dev.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/uwb/lc-dev.c
++++ b/drivers/uwb/lc-dev.c
+@@ -431,16 +431,19 @@ void uwbd_dev_onair(struct uwb_rc *rc, s
+ uwb_dev->mac_addr = *bce->mac_addr;
+ uwb_dev->dev_addr = bce->dev_addr;
+ dev_set_name(&uwb_dev->dev, "%s", macbuf);
++
++ /* plug the beacon cache */
++ bce->uwb_dev = uwb_dev;
++ uwb_dev->bce = bce;
++ uwb_bce_get(bce); /* released in uwb_dev_sys_release() */
++
+ result = uwb_dev_add(uwb_dev, &rc->uwb_dev.dev, rc);
+ if (result < 0) {
+ dev_err(dev, "new device %s: cannot instantiate device\n",
+ macbuf);
+ goto error_dev_add;
+ }
+- /* plug the beacon cache */
+- bce->uwb_dev = uwb_dev;
+- uwb_dev->bce = bce;
+- uwb_bce_get(bce); /* released in uwb_dev_sys_release() */
++
+ dev_info(dev, "uwb device (mac %s dev %s) connected to %s %s\n",
+ macbuf, devbuf, rc->uwb_dev.dev.parent->bus->name,
+ dev_name(rc->uwb_dev.dev.parent));
+@@ -448,6 +451,8 @@ void uwbd_dev_onair(struct uwb_rc *rc, s
+ return;
+
+ error_dev_add:
++ bce->uwb_dev = NULL;
++ uwb_bce_put(bce);
+ kfree(uwb_dev);
+ return;
+ }
--- /dev/null
+From c207e7c50f31113c24a9f536fcab1e8a256985d7 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Thu, 11 Sep 2014 13:55:48 +0300
+Subject: xhci: Fix null pointer dereference if xhci initialization fails
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit c207e7c50f31113c24a9f536fcab1e8a256985d7 upstream.
+
+If xhci initialization fails before the roothub bandwidth
+domains (xhci->rh_bw[i]) are allocated it will oops when
+trying to access rh_bw members in xhci_mem_cleanup().
+
+Reported-by: Manuel Reimer <manuel.reimer@gmx.de>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-mem.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -1723,7 +1723,7 @@ void xhci_mem_cleanup(struct xhci_hcd *x
+ }
+
+ num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
+- for (i = 0; i < num_ports; i++) {
++ for (i = 0; i < num_ports && xhci->rh_bw; i++) {
+ struct xhci_interval_bw_table *bwt = &xhci->rh_bw[i].bw_table;
+ for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
+ struct list_head *ep = &bwt->interval_bw[j].endpoints;
--- /dev/null
+From 96044694b8511bc2b04df0776b4ba295cfe005c0 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Thu, 11 Sep 2014 13:55:50 +0300
+Subject: xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 96044694b8511bc2b04df0776b4ba295cfe005c0 upstream.
+
+Resuming from hibernate (S4) will restart and re-initialize xHC.
+The device contexts are freed and will be re-allocated later during device reset.
+
+Usb core will disable link pm in device resume before device reset, which will
+try to change the max exit latency, accessing the device contexts before they are re-allocated.
+
+There is no need to zero (disable) the max exit latency when disabling hw lpm
+for a freshly re-initialized xHC. So check that device context exists before
+doing anything. The max exit latency will be set again after device reset when usb core
+enables the link pm.
+
+Reported-by: Imre Deak <imre.deak@intel.com>
+Tested-by: Imre Deak <imre.deak@intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -3928,13 +3928,21 @@ static int __maybe_unused xhci_change_ma
+ int ret;
+
+ spin_lock_irqsave(&xhci->lock, flags);
+- if (max_exit_latency == xhci->devs[udev->slot_id]->current_mel) {
++
++ virt_dev = xhci->devs[udev->slot_id];
++
++ /*
++ * virt_dev might not exists yet if xHC resumed from hibernate (S4) and
++ * xHC was re-initialized. Exit latency will be set later after
++ * hub_port_finish_reset() is done and xhci->devs[] are re-allocated
++ */
++
++ if (!virt_dev || max_exit_latency == virt_dev->current_mel) {
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ return 0;
+ }
+
+ /* Attempt to issue an Evaluate Context command to change the MEL. */
+- virt_dev = xhci->devs[udev->slot_id];
+ command = xhci->lpm_command;
+ ctrl_ctx = xhci_get_input_control_ctx(xhci, command->in_ctx);
+ if (!ctrl_ctx) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
