From 555ef95eb4c1c2a208f00350630a372e84ea37cc Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 22 Jul 2014 17:04:35 -0700 Subject: [PATCH] 3.15-stable patches added patches: media-gspca_pac7302-add-new-usb-id-for-genius-i-look-317.patch usb-check-if-port-status-is-equal-to-rxdetect.patch usb-chipidea-udc-disable-auto-zlp-generation-on-ep0.patch --- ...add-new-usb-id-for-genius-i-look-317.patch | 29 ++++++ queue-3.15/series | 3 + ...-if-port-status-is-equal-to-rxdetect.patch | 58 ++++++++++++ ...c-disable-auto-zlp-generation-on-ep0.patch | 93 +++++++++++++++++++ 4 files changed, 183 insertions(+) create mode 100644 queue-3.15/media-gspca_pac7302-add-new-usb-id-for-genius-i-look-317.patch create mode 100644 queue-3.15/usb-check-if-port-status-is-equal-to-rxdetect.patch create mode 100644 queue-3.15/usb-chipidea-udc-disable-auto-zlp-generation-on-ep0.patch diff --git a/queue-3.15/media-gspca_pac7302-add-new-usb-id-for-genius-i-look-317.patch b/queue-3.15/media-gspca_pac7302-add-new-usb-id-for-genius-i-look-317.patch new file mode 100644 index 00000000000..47f8783f557 --- /dev/null +++ b/queue-3.15/media-gspca_pac7302-add-new-usb-id-for-genius-i-look-317.patch @@ -0,0 +1,29 @@ +From 242841d3d71191348f98310e2d2001e1001d8630 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +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 + +commit 242841d3d71191348f98310e2d2001e1001d8630 upstream. + +Tested-and-reported-by: yullaw + +Signed-off-by: Hans de Goede +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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)}, diff --git a/queue-3.15/series b/queue-3.15/series index e69de29bb2d..ab67dc8dfe9 100644 --- a/queue-3.15/series +++ b/queue-3.15/series @@ -0,0 +1,3 @@ +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 diff --git a/queue-3.15/usb-check-if-port-status-is-equal-to-rxdetect.patch b/queue-3.15/usb-check-if-port-status-is-equal-to-rxdetect.patch new file mode 100644 index 00000000000..0d4c82be8f4 --- /dev/null +++ b/queue-3.15/usb-check-if-port-status-is-equal-to-rxdetect.patch @@ -0,0 +1,58 @@ +From bb86cf569bbd7ad4dce581a37c7fbd748057e9dc Mon Sep 17 00:00:00 2001 +From: Gavin Guo +Date: Fri, 18 Jul 2014 01:12:13 +0800 +Subject: usb: Check if port status is equal to RxDetect + +From: Gavin Guo + +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 +Acked-by: Alan Stern +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/hub.c | 19 +++++++++++++++++++ + 1 file changed, 19 insertions(+) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -893,6 +893,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; diff --git a/queue-3.15/usb-chipidea-udc-disable-auto-zlp-generation-on-ep0.patch b/queue-3.15/usb-chipidea-udc-disable-auto-zlp-generation-on-ep0.patch new file mode 100644 index 00000000000..0c108d94577 --- /dev/null +++ b/queue-3.15/usb-chipidea-udc-disable-auto-zlp-generation-on-ep0.patch @@ -0,0 +1,93 @@ +From 953c66469735aed8d2ada639a72b150f01dae605 Mon Sep 17 00:00:00 2001 +From: Abbas Raza +Date: Thu, 17 Jul 2014 19:34:31 +0800 +Subject: usb: chipidea: udc: Disable auto ZLP generation on ep0 + +From: Abbas Raza + +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 +Signed-off-by: Peter Chen +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1176,8 +1176,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 -- 2.47.3