--- /dev/null
+From 242841d3d71191348f98310e2d2001e1001d8630 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 9 Jul 2014 06:20:44 -0300
+Subject: media: gspca_pac7302: Add new usb-id for Genius i-Look 317
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 242841d3d71191348f98310e2d2001e1001d8630 upstream.
+
+Tested-and-reported-by: yullaw <yullaw@mageia.cz>
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/gspca/pac7302.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/usb/gspca/pac7302.c
++++ b/drivers/media/usb/gspca/pac7302.c
+@@ -928,6 +928,7 @@ static const struct usb_device_id device
+ {USB_DEVICE(0x093a, 0x2620)},
+ {USB_DEVICE(0x093a, 0x2621)},
+ {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
++ {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2625)},
+ {USB_DEVICE(0x093a, 0x2626)},
+usb-check-if-port-status-is-equal-to-rxdetect.patch
+usb-chipidea-udc-disable-auto-zlp-generation-on-ep0.patch
+media-gspca_pac7302-add-new-usb-id-for-genius-i-look-317.patch
--- /dev/null
+From bb86cf569bbd7ad4dce581a37c7fbd748057e9dc Mon Sep 17 00:00:00 2001
+From: Gavin Guo <gavin.guo@canonical.com>
+Date: Fri, 18 Jul 2014 01:12:13 +0800
+Subject: usb: Check if port status is equal to RxDetect
+
+From: Gavin Guo <gavin.guo@canonical.com>
+
+commit bb86cf569bbd7ad4dce581a37c7fbd748057e9dc upstream.
+
+When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
+[1022:7814], the second hotplugging will experience the USB 3.0 pen
+drive is recognized as high-speed device. After bisecting the kernel,
+I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
+(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
+some experiments, the bug can be fixed by avoiding executing the function
+hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
+XHCI Controlleris [1022:7814] is already in RxDetect
+(I tried printing out the port status before setting to Disabled state),
+it's reasonable to check the port status before really executing
+hub_usb3_port_disable().
+
+Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
+Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hub.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -884,6 +884,25 @@ static int hub_usb3_port_disable(struct
+ if (!hub_is_superspeed(hub->hdev))
+ return -EINVAL;
+
++ ret = hub_port_status(hub, port1, &portstatus, &portchange);
++ if (ret < 0)
++ return ret;
++
++ /*
++ * USB controller Advanced Micro Devices, Inc. [AMD] FCH USB XHCI
++ * Controller [1022:7814] will have spurious result making the following
++ * usb 3.0 device hotplugging route to the 2.0 root hub and recognized
++ * as high-speed device if we set the usb 3.0 port link state to
++ * Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT state, we
++ * check the state here to avoid the bug.
++ */
++ if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
++ USB_SS_PORT_LS_RX_DETECT) {
++ dev_dbg(&hub->ports[port1 - 1]->dev,
++ "Not disabling port; link state is RxDetect\n");
++ return ret;
++ }
++
+ ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
+ if (ret)
+ return ret;
--- /dev/null
+From 953c66469735aed8d2ada639a72b150f01dae605 Mon Sep 17 00:00:00 2001
+From: Abbas Raza <Abbas_Raza@mentor.com>
+Date: Thu, 17 Jul 2014 19:34:31 +0800
+Subject: usb: chipidea: udc: Disable auto ZLP generation on ep0
+
+From: Abbas Raza <Abbas_Raza@mentor.com>
+
+commit 953c66469735aed8d2ada639a72b150f01dae605 upstream.
+
+There are 2 methods for ZLP (zero-length packet) generation:
+1) In software
+2) Automatic generation by device controller
+
+1) is implemented in UDC driver and it attaches ZLP to IN packet if
+ descriptor->size < wLength
+2) can be enabled/disabled by setting ZLT bit in the QH
+
+When gadget ffs is connected to ubuntu host, the host sends
+get descriptor request and wLength in setup packet is 255 while the
+size of descriptor which will be sent by gadget in IN packet is
+64 byte. So the composite driver sets req->zero = 1.
+In UDC driver following code will be executed then
+
+ if (hwreq->req.zero && hwreq->req.length
+ && (hwreq->req.length % hwep->ep.maxpacket == 0))
+ add_td_to_list(hwep, hwreq, 0);
+
+Case-A:
+So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
+ubuntu host will request 255 byte in IN request, gadget will send 64 byte
+with ZLP and host will come to know that there is no more data.
+But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
+automatically generate the ZLP which blocks enumeration for ~6 seconds due
+to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)
+
+Case-B:
+In case when gadget ffs is connected to Apple device, Apple device sends
+setup packet with wLength=64. So descriptor->size = 64 and wLength=64
+therefore req->zero = 0 and UDC driver will not attach any ZLP to the
+IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
+further request for IN data. But ZLT=0 by default for endpoint 0 so
+hardware tries to automatically generate the ZLP which blocks enumeration
+for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
+requests (OUT/PING)
+
+According to USB2.0 specs:
+
+ 8.5.3.2 Variable-length Data Stage
+ A control pipe may have a variable-length data phase in which the
+ host requests more data than is contained in the specified data
+ structure. When all of the data structure is returned to the host,
+ the function should indicate that the Data stage is ended by
+ returning a packet that is shorter than the MaxPacketSize for the
+ pipe. If the data structure is an exact multiple of wMaxPacketSize
+ for the pipe, the function will return a zero-length packet to indicate
+ the end of the Data stage.
+
+In Case-A mentioned above:
+If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software
+ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
+enumeration doesn't block for 6 seconds.
+
+In Case-B mentioned above:
+If we disable software ZLP generation & ZLT=0 for endpoint then enumeration
+still blocks due to ZLP automatically generated by hardware and host not needing
+it. But if we keep software ZLP generation enabled but we set ZLT=1 for
+endpoint 0 then enumeration doesn't block for 6 seconds.
+
+So the proper solution for this issue seems to disable automatic ZLP generation
+by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
+handle the ZLP generation based on req->zero field.
+
+Signed-off-by: Abbas Raza <Abbas_Raza@mentor.com>
+Signed-off-by: Peter Chen <peter.chen@freescale.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/chipidea/udc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/chipidea/udc.c
++++ b/drivers/usb/chipidea/udc.c
+@@ -1179,8 +1179,8 @@ static int ep_enable(struct usb_ep *ep,
+
+ if (hwep->type == USB_ENDPOINT_XFER_CONTROL)
+ cap |= QH_IOS;
+- if (hwep->num)
+- cap |= QH_ZLT;
++
++ cap |= QH_ZLT;
+ cap |= (hwep->ep.maxpacket << __ffs(QH_MAX_PKT)) & QH_MAX_PKT;
+ /*
+ * For ISO-TX, we set mult at QH as the largest value, and use
projects / thirdparty / kernel / stable-queue.git / commitdiff
