summaryrefslogtreecommitdiffstats
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2012-09-12Merge branch 'chipidea-stable' into usb-linusGreg Kroah-Hartman1-18/+41
Chipidea patches for 3.6 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12usb: chipidea: udc: don't stall endpoint if request list is empty in ↵Michael Grzeschik1-4/+1
isr_tr_complete_low When attaching an imx28 or imx53 in USB gadget mode to a Windows host and starting a rndis connection we see this message every 4-10 seconds: g_ether gadget: high speed config #2: RNDIS Analysis shows that each time this message is printed, the rndis connection is re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The endpoint is stalled because the reqeust complete bit on that endpoint is set, but in isr_tr_complete_low() the endpoint request list (mEp->qh.queue) is empty. This patch removed this check, because the code doesn't take the following situation into account: The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed and completed here. There seems to be a race condition, the request is nuked, but the request complete bit will be set, too. The subsequent check (in ep0/dir1's loop cycle) for endpoint request list (mEp->qh.queue) empty will fail. Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't have this check. Cc: stable <stable@vger.kernel.org> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12usb: chipidea: cleanup dma_pool if udc_start() failsMarc Kleine-Budde1-8/+15
If udc_start() fails the qh_pool dma-pool cannot be closed because it's still in use. This patch factors out the dma_pool_free() loop into destroy_eps() and calls it in the error path of udc_start(), too. Cc: stable <stable@vger.kernel.org> Reviewed-by: Richard Zhao <richard.zhao@freescale.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12usb: chipidea: udc: fix error path in udc_start()Marc Kleine-Budde1-1/+1
This patch fixes the error path of udc_start(). Now NULL is used to unset the peripheral with otg_set_peripheral(). Cc: stable <stable@vger.kernel.org> Reviewed-by: Richard Zhao <richard.zhao@freescale.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12usb: chipidea: udc: add pullup fuction, needed by the uvc gadgetMichael Grzeschik1-4/+17
Add function to physicaly enable or disable of pullup connection on the USB-D+ line. The uvc gaget will fail, if this function is not implemented. Cc: stable <stable@vger.kernel.org> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12usb: chipidea: udc: fix setup of endpoint maxpacket sizeMichael Grzeschik1-1/+7
This patch changes the setup of the endpoint maxpacket size. All non control endpoints are initialized with an undefined ((unsigned short)~0) maxpacket size. The maxpacket size of Endpoint 0 will be kept at CTRL_PAYLOAD_MAX. Some gadget drivers check for the maxpacket size before they enable the endpoint, which leads to a wrong state in these drivers. Cc: stable <stable@vger.kernel.org> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-11USB: option: replace ZTE K5006-Z entry with vendor class ruleBjørn Mork1-2/+4
Fix the ZTE K5006-Z entry so that it actually matches anything commit f1b5c997 USB: option: add ZTE K5006-Z added a device specific entry assuming that the device would use class/subclass/proto == ff/ff/ff like other ZTE devices. It turns out that ZTE has started using vendor specific subclass and protocol codes: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1018 Rev= 0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE LTE Technologies MSM S: SerialNumber=MF821Vxxxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms We do not have any information on how ZTE intend to use these codes, but let us assume for now that the 3 sets matching serial functions in the K5006-Z always will identify a serial function in a ZTE device. Cc: Thomas Schäfer <tschaefer@t-online.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-10EHCI: Update qTD next pointer in QH overlay region during unlinkPavankumar Kondeti1-2/+10
There is a possibility of QH overlay region having reference to a stale qTD pointer during unlink. Consider an endpoint having two pending qTD before unlink process begins. The endpoint's QH queue looks like this. qTD1 --> qTD2 --> Dummy To unlink qTD2, QH is removed from asynchronous list and Asynchronous Advance Doorbell is programmed. The qTD1's next qTD pointer is set to qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell interrupt. If QH's current qTD pointer points to qTD1, transfer overlay region still have reference to qTD2. But qtD2 is just unlinked and freed. This may cause EHCI system error. Fix this by updating qTD next pointer in QH overlay region with the qTD next pointer of the current qTD. Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-10USB: cdc-wdm: fix wdm_find_device* return valueBjørn Mork1-4/+8
A logic error made the wdm_find_device* functions return a bogus pointer into static data instead of the intended NULL no matching device was found. Cc: stable <stable@vger.kernel.org> # v3.4+ Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-10USB: ftdi_sio: do not claim CDC ACM functionBjørn Mork2-2/+7
The Microchip vid:pid 04d8:000a is used for their CDC ACM demo firmware application. This is a device with a single function conforming to the CDC ACM specification and with the intention of demonstrating CDC ACM class firmware and driver interaction. The demo is used on a number of development boards, and may also be used unmodified by vendors using Microchip hardware. Some vendors have re-used this vid:pid for other types of firmware, emulating FTDI chips. Attempting to continue to support such devices without breaking class based applications that by matching on interface class/subclass/proto being ff/ff/00. I have no information about the actual device or interface descriptors, but this will at least make the proper CDC ACM devices work again. Anyone having details of the offending device's descriptors should update this entry with the details. Reported-by: Florian Wöhrl <fw@woehrl.biz> Reported-by: Xiaofan Chen <xiaofanc@gmail.com> Cc: stable <stable@vger.kernel.org> Cc: Alan Cox <alan@linux.intel.com> Cc: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-07Merge tag 'fixes-for-v3.6-rc4' of ↵Greg Kroah-Hartman12-19/+78
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into work-linus usb: fixes for v3.6-rc4 Here's a rather big set of fixes for v3.6-rc4. There are some fixes for bugs which have been pending for a long time and only now were uncovered, like the musb and dwc3 patches. We have some remaining fixes for the ep->desc patch series from Ido, a fix for renesas DMA usage, IRQ check on musb's DMA and an oops fix on musb Host implementation. All patches have been pending on linux-usb for a long time and shouldn't cause any further regressions.
2012-09-06usb: dwc3: gadget: fix pending isoc handlingPratyush Anand1-0/+12
If xfernotready is received and there is no request in request_list then REQUEST_PENDING flag must be set, so that next request in ep queue is executed. In case of isoc transfer, if xfernotready is already elapsed and even first request has not been queued to request_list, then issue END TRANSFER, so that you can receive xfernotready again and can have notion of current microframe. Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: renesas_usbhs: fixup DMA transport data alignmentKuninori Morimoto1-2/+2
renesas_usbhs dma can transport 8byte alignment data, not 4byte. This patch fixup it. Reported-by: Sugnan Prabhu S <sugnan.prabhu@renesasmobile.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: gadget: at91udc: Don't check for ep->ep.descSebastian Andrzej Siewior1-3/+1
Earlier we used to check for ep->ep.desc to figure out if this ep has already been enabled and if so, abort. Ido Shayevitz removed the usb_endpoint_descriptor from private udc structure 5a6506f00 ("usb: gadget: Update at91_udc to use usb_endpoint_descriptor inside the struct usb_ep") but did not fix up the ep_enable condition because _now_ the member is always true and we can't check if this ep is enabled twice. Cc: Ido Shayevitz <idos@codeaurora.org> Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com> Tested-by: Mario Isidoro <Mario.Isidoro@tecmic.pt> Cc: <stable@kernel.org> # v3.5 Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: gadget: at91udc: don't overwrite driver dataSebastian Andrzej Siewior1-2/+0
The driver was converted to the new start/stop interface in f3d8bf34c2 ("usb: gadget: at91_udc: convert to new style start/stop interface"). I overlooked that the driver is overwritting the private data which is used by the composite framework. The udc driver doesn't read it, it is only written here. Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com> Tested-by: Mario Isidoro <Mario.Isidoro@tecmic.pt> Cc: <stable@kernel.org> # v3.5 Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: dwc3: core: fix incorrect usage of resource pointerKishon Vijay Abraham I1-2/+7
Populate the resources for xhci afresh instead of directly using the *struct resource* of core. *resource* structure has parent, sibling, child pointers which should be filled only by resource API's. By directly using the *resource* pointer of core in xhci, these parent, sibling, child pointers are already populated even before *platform_device_add* causing side effects. Cc: stable@vger.kernel.org # v3.4, v3.5 Reported-by: Ruchika Kharwar <ruchika@ti.com> Tested-by: Moiz Sonasath <m-sonasath@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: musb: musbhsdma: fix IRQ checkSergei Shtylyov1-1/+1
dma_controller_create() in this MUSB DMA driver only regards 0 as a wrong IRQ number, despite platform_get_irq_byname() that it calls returns -ENXIO in that case. It leads to calling request_irq() with a negative IRQ number, and when it naturally fails, the following is printed to the console: request_irq -6 failed! and the DMA controller is not created. Fix this function to filter out the error values as well as 0. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: musb: tusb6010: fix error path in tusb_probe()Sergei Shtylyov1-1/+1
On platform_device_add() failure, the TUSB6010 glue layer forgets to call platform_device_put() -- probably due to a typo... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: musb: host: fix for musb_start_urb Oopsyuzheng ma1-1/+1
when using musb_urb_enqueue to submit three urbs to the same endpoint, when hep->hcpriv is NULL, qh will be allocated when the first urb is completed. When the IRQ completes the next two urbs, qh->hep->hcpriv will be set to NULL. Now the second urb get musb->lock and executes musb_schedule(), but next_urb(qh) is NULL, so musb_start_urb will Oops. [ balbi@ti.com : practically rewrote commit log so it makes sense ] Signed-off-by: mayuzheng <myz147@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: gadget: dummy_hcd: add support for USB_DT_BOS on rhSebastian Andrzej Siewior1-0/+33
Without a reply for USB_DT_BOS the USB3 mode does not work since 448b6eb1 ("USB: Make sure to fetch the BOS desc for roothubs.). Cc: stable@vger.kernel.org #v3.5 Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: gadget: dummy_hcd: fixup error probe pathSebastian Andrzej Siewior1-4/+4
If USB2 host controller probes fine but USB3 does not then we don't remove the USB controller properly and lock up the system while the HUB code will try to enumerate the USB2 controller and access memory which is no longer available in case the dummy_hcd was compiled as a module. This is a problem since 448b6eb1 ("USB: Make sure to fetch the BOS desc for roothubs.) if used in USB3 mode because dummy does not provide this descriptor and explodes later. Cc: stable@vger.kernel.org # v3.5 Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: gadget: s3c-hsotg.c: fix error return codeJulia Lawall1-0/+3
Convert a 0 error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e,e1,e2,e3,e4,x; @@ ( if (\(ret != 0\|ret < 0\) || ...) { ... return ...; } | ret = 0 ) ... when != ret = e1 *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...); ... when != x = e2 when != ret = e3 *if (x == NULL || ...) { ... when != ret = e4 * return ret; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: dwc3: ep0: correct cache sync issue in case of ep0_bouncedPratyush Anand2-3/+5
In case of ep0 out, if length is not aligned to maxpacket size then we use dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we have alreday done memcpy from dwc->ep0_bounce to request->buf, so we do not need to issue cache sync function. In fact, cache sync function will bring wrong data in request->buf from request->dma in this scenario. So, cache sync function must not be executed in case of ep0 bounced. Cc: <stable@vger.kernel.org> # v3.4 v3.5 Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-06usb: gadget: add multiple definition guardsAndrzej Pietrasiewicz2-0/+8
If f_fs.c and u_serial.c are combined together using #include, which has been a common practice so far, the pr_vdebug macro is defined multiple times. Define it only once. Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2012-09-05Merge tag 'for-usb-linus-2012-09-05' of ↵Greg Kroah-Hartman6-9/+207
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus xHCI 3.6 bug fixes. Hi Greg, Here's seven bugfixes for 3.6. All of them are marked for stable, and most are vendor-specific fixes. Details: -------- - Commits 052c7f9 and 2963657 fix a couple stupid mistakes I made in a Intel xHCI bug fix patch I pushed just before I left for vacation. - Commits 29d2145 and a96874a fix issues with the Intel Panther Point EHCI to xHCI port switchover. - Commit 71c731a adds the work-around for the TI redriver "dead port" issue. - Commit 319acdf adds a fix for non-PCI xHCI platform drivers. - Commit e955a1c works around the UEFI issue with the xHCI host sometimes returning 0xff's in the MMIO on boot. Sarah Sharp
2012-09-05USB: add device quirk for Joss Optical touchboardAlan Stern1-0/+4
This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss infrared touchboard device. The device doesn't like to be asked for its interface strings. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: adam ? <adam3337@wp.pl> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05USB: ohci-at91: fix PIO handling in relation with number of portsNicolas Ferre1-0/+10
If the number of ports present on the SoC/board is not the maximum and that the platform data is not filled with all data, there is an easy way to mess the PIO setup for this interface. This quick fix addresses mis-configuration in USB host platform data that is common in at91 boards since commit 0ee6d1e (USB: ohci-at91: change maximum number of ports) that did not modified the associatd board files. Reported-by: Klaus Falkner <klaus.falkner@solectrix.de> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Stable <stable@vger.kernel.org> [3.4+] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05USB: ftdi_sio: PID for NZR SEM 16+ USBHorst Schirmeier2-0/+4
This adds the USB PID for the NZR SEM 16+ USB energy monitor device <http://www.nzr.de>. It works perfectly with the GPL software on <http://schou.dk/linux/sparometer/>. Signed-off-by: Horst Schirmeier <horst@schirmeier.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05USB: ftdi-sio: add support for more Physik Instrumente devicesÉric Piel2-1/+37
Commit b69cc672052540 added support for the E-861. After acquiring a C-867, I realised that every Physik Instrumente's device has a different PID. They are listed in the Windows device driver's .inf file. So here are all PIDs for the current (and probably future) USB devices from Physik Instrumente. Compiled, but only actually tested on the E-861 and C-867. Signed-off-by: Éric Piel <piel@delmic.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05usb: host: xhci: fix compilation error for non-PCI based stacksMoiz Sonasath1-0/+1
For non PCI-based stacks, this function call usb_disable_xhci_ports(to_pci_dev(hcd->self.controller)); made from xhci_shutdown is not applicable. Ideally, we wouldn't have any PCI-specific code on a generic driver such as the xHCI stack, but it looks like we should just stub usb_disable_xhci_ports() out for non-PCI devices. [ balbi@ti.com: slight improvement to commit log ] This patch should be backported to kernels as old as 3.0, since the commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown.") was marked for stable. Signed-off-by: Moiz Sonasath<m-sonasath@ti.com> Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-05usb: host: xhci-plat: use ioremap_nocacheRuchika Kharwar1-1/+1
Use the ioremap_nocache variant of the ioremap API in order to make sure our memory will be marked uncachable. This patch should be backported to kernels as old as 3.4, that contain the commit 3429e91a661e1f383aecc86c6bbcf65afb15c892 "usb: host: xhci: add platform driver support". Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-05usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP HardwareAlexis R. Cortes3-0/+169
This patch is intended to work around a known issue on the SN65LVPE502CP USB3.0 re-driver that can delay the negotiation between a device and the host past the usual handshake timeout. If that happens on the first insertion, the host controller port will enter in Compliance Mode and NO port status event will be generated (as per xHCI Spec) making impossible to detect this event by software. The port will remain in compliance mode until a warm reset is applied to it. As a result of this, the port will seem "dead" to the user and no device connections or disconnections will be detected. For solving this, the patch creates a timer which polls every 2 seconds the link state of each host controller's port (this by reading the PORTSC register) and recovers the port by issuing a Warm reset every time Compliance mode is detected. If a xHC USB3.0 port has previously entered to U0, the compliance mode issue will NOT occur only until system resumes from sleep/hibernate, therefore, the compliance mode timer is stopped when all xHC USB 3.0 ports have entered U0. The timer is initialized again after each system resume. Since the issue is being caused by a piece of hardware, the timer will be enabled ONLY on those systems that have the SN65LVPE502CP installed (this patch uses DMI strings for detecting those systems) therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK has been added to the xhci stack). This patch applies for these systems: Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820. This patch should be backported to kernels as old as 3.2, as that was the first kernel to support warm reset. The kernels will need to contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When hot reset for USB3 fails, try warm reset" and commit 8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub port status CAS". The first patch add warm reset support, and the second patch modifies the USB core to issue a warm reset when the port is in compliance mode. Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-05xhci: Make handover code more robustMatthew Garrett1-2/+10
My test platform (Intel DX79SI) boots reliably under BIOS, but frequently crashes when booting via UEFI. I finally tracked this down to the xhci handoff code. It seems that reads from the device occasionally just return 0xff, resulting in xhci_find_next_cap_offset generating a value that's larger than the resource region. We then oops when attempting to read the value. Sanity checking that value lets us avoid the crash. I've no idea what's causing the underlying problem, and xhci still doesn't actually *work* even with this, but the machine at least boots which will probably make further debugging easier. This should be backported to kernels as old as 2.6.31, that contain the commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff and HW initialization." Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-05xhci: Fix a logical vs bitwise AND bugDan Carpenter1-1/+1
The intent was to test whether the flag was set. This patch should be backported to stable kernels as old as 3.0, since it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown.", which was marked for stable. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-04Intel xhci: Only switch the switchable portsKeng-Yu Lin1-4/+23
With a previous patch to enable the EHCI/XHCI port switching, it switches all the available ports. The assumption is not correct because the BIOS may expect some ports not switchable by the OS. There are two more registers that contains the information of the switchable and non-switchable ports. This patch adds the checking code for the two register so that only the switchable ports are altered. This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-04xhci: Recognize USB 3.0 devices as superspeed at powerupManoj Iyer1-1/+2
On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. BugLink: http://bugs.launchpad.net/bugs/1000424 This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-08-20Merge tag 'usb-3.6-rc3' of ↵Linus Torvalds3-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull more USB patches from Greg Kroah-Hartman: "Here are 10 more USB patches for 3.6-rc3. They all fix reported problems (build problems for one of them, and easily repeatable oopses for the others.) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>" * tag 'usb-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: gpu/mfd/usb: Fix USB randconfig problems USB: CDC ACM: Fix NULL pointer dereference USB: emi62: remove __devinit* from the struct usb_device_id table USB: winbond: remove __devinit* from the struct usb_device_id table USB: vt6656: remove __devinit* from the struct usb_device_id table USB: rtl8187: remove __devinit* from the struct usb_device_id table USB: p54usb: remove __devinit* from the struct usb_device_id table USB: spca506: remove __devinit* from the struct usb_device_id table USB: jl2005bcd: remove __devinit* from the struct usb_device_id table USB: smsusb: remove __devinit* from the struct usb_device_id table
2012-08-20gpu/mfd/usb: Fix USB randconfig problemsGuenter Roeck1-1/+1
Fix config warning: warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) and build error: ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined! by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB which is due to drivers/usb/Kconfig: config USB_ARCH_HAS_OHCI ... default y if ARCH_PNX4008 && I2C Fix by dropping I2C from the above dependency; logic is that this is not a platform dependency but a configuration dependency: the _architecture_ still supports USB even is I2C is not selected. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB drivers/mfd/Kconfig:396: symbol MFD_TC6393XB depends on GPIOLIB drivers/gpio/Kconfig:35: symbol GPIOLIB is selected by FB_VIA drivers/video/Kconfig:1560: symbol FB_VIA depends on FB which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-17USB: CDC ACM: Fix NULL pointer dereferenceSven Schnelle1-1/+2
If a device specifies zero endpoints in its interface descriptor, the kernel oopses in acm_probe(). Even though that's clearly an invalid descriptor, we should test wether we have all endpoints. This is especially bad as this oops can be triggered by just plugging a USB device in. Signed-off-by: Sven Schnelle <svens@stackframe.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-17USB: emi62: remove __devinit* from the struct usb_device_id tableGreg Kroah-Hartman1-1/+1
This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reported-by: Bjørn Mork <bjorn@mork.no> Cc: stable <stable@vger.kernel.org> CC: Paul Gortmaker <paul.gortmaker@windriver.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-17Merge tag 'usb-3.6-rc3' of ↵Linus Torvalds25-452/+294
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB patches from Greg Kroah-Hartman: "Here are a number of small USB patches for 3.6-rc3. The "large" one is just a number of device id updates to the option driver, done by the manufacturer, properly fixing up the device ids based on shipping devices. Other than that, some gadget driver fixes, the obligitary XHCI patches, and some other device ids and bugs fixed. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>" * tag 'usb-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (26 commits) USB: qcserial: fix port handling on Gobi 1K and 2K+ USB: serial: Fix mos7840 timeout USB: option: add ZTE K5006-Z usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop usb: host: tegra: fix warning messages in ehci_remove usb: host: mips: sead3: Update for EHCI register structure. usb: renesas_usbhs: fixup resume method for autonomy mode usb: renesas_usbhs: mod_host: add missing .bus_suspend/resume update MAINTAINERS for Oliver Neukum usb: usb_wwan: resume/suspend can be called after port is gone usb: serial: prevent suspend/resume from racing against probe/remove usb: usb_wwan: replace release and disconnect with a port_remove hook usb: serial: mos7840: Fixup mos7840_chars_in_buffer() USB: isp1362-hcd.c: usb message always saved in case of underrun OMAP: USB : Fix the EHCI enumeration and core retention issue usb: chipidea: fix and improve dependencies if usb host or gadget support is built as module USB: support the new interfaces of Huawei Data Card devices in option driver USB: ftdi_sio: Add VID/PID for Kondo Serial USB xhci: Switch PPT ports to EHCI on shutdown. xhci: Fix bug after deq ptr set to link TRB. ...
2012-08-16USB: qcserial: fix port handling on Gobi 1K and 2K+Dan Williams1-18/+24
Bjorn's latest patchset does break Gobi 1K and 2K because on both devices as it claims usb interface 0. That's because usbif 0 is not handled in the switch statement, and thus the if0 gets claimed when it should not. So let's just make things even simpler yet, and handle both the 1K and 2K+ cases separately. This patch should not affect the new Sierra device support, because those devices are matched via interface-specific matching and thus should never hit the composite code. Signed-off-by: Dan Williams <dcbw@redhat.com> Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-15USB: serial: Fix mos7840 timeoutMark Ferrell1-4/+3
* mos7840 driver was using multiple of HZ for the timeout handed off to usb_control_msg(). Changed the timeout to use msecs instead. * Remove unused WAIT_FOR_EVER definition Signed-off-by: Mark Ferrell <mferrell@uplogix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-15USB: option: add ZTE K5006-ZBjørn Mork1-0/+2
The ZTE (Vodafone) K5006-Z use the following interface layout: 00 DIAG 01 secondary 02 modem 03 networkcard 04 storage Ignoring interface #3 which is handled by the qmi_wwan driver. Cc: Thomas Schäfer <tschaefer@t-online.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-12Merge tag 'fixes-for-linus' of ↵Linus Torvalds1-2/+0
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull arm-soc bug fixes from Arnd Bergmann: "These are a bunch of bug fixes that came in after the merge window and one update for the MAINTAINERS file. The largest part of the fixes are patches that address bugs found by building all the ARM defconfig files. There are a lot more warnings that we have patches for, but the others are either still under discussion or are harmless and do not cause actual problems besides making the build slightly noisy." * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (30 commits) ARM: davinci: remove broken ntosd2_init_i2c ARM: s3c24xx: enable CONFIG_BUG for tct_hammer omap-rng: fix use of SIMPLE_DEV_PM_OPS spi/s3c64xx: improve error handling mtd/omap2: fix dmaengine_slave_config error handling gpio: em: do not discard em_gio_irq_domain_cleanup ARM: exynos: exynos_pm_add_dev_to_genpd may be unused ARM: imx: gpmi-nand depends on mxs-dma ARM: integrator: include <linux/export.h> ARM: s3c24xx: use new PWM driver ARM: sa1100: include linux/io.h in hackkit leds code Input: eeti_ts: pass gpio value instead of IRQ ARM: pxa: remove irq_to_gpio from ezx-pcap driver ARM: tegra: more regulator fixes for Harmony usb/ohci-omap: remove unused variable mfd/asic3: fix asic3_mfd_probe return value ARM: kirkwood: fix typo in Makefile.boot i.MX27: Fix emma-prp and csi clocks. ARM: integrator: use clk_prepare_enable() for timer MAINTAINERS: update entry for Linus Walleij ...
2012-08-10usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces ↵Michael Grzeschik1-0/+6
in eth_stop This patch fixes an issue introduced by patch: 72c973d usb: gadget: add usb_endpoint_descriptor to struct usb_ep Without this patch we see a kworker taking 100% CPU, after this sequence: - Connect gadget to a windows host - load g_ether - ifconfig up <ip>; ifconfig down; ifconfig up - ping <windows host> The "ifconfig down" results in calling eth_stop(), which will call usb_ep_disable() and, if the carrier is still ok, usb_ep_enable(): usb_ep_disable(link->in_ep); usb_ep_disable(link->out_ep); if (netif_carrier_ok(net)) { usb_ep_enable(link->in_ep); usb_ep_enable(link->out_ep); } The ep should stay enabled, but will not, as ep_disable set the desc pointer to NULL, therefore the subsequent ep_enable will fail. This leads to permanent rescheduling of the eth_work() worker as usb_ep_queue() (called by the worker) will fail due to the unconfigured endpoint. We fix this issue by saving the ep descriptors and re-assign them before usb_ep_enable(). Cc: Tatyana Brokhman <tlinder@codeaurora.org> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-10usb: host: tegra: fix warning messages in ehci_removeVenu Byravarasu1-1/+2
Existing implementation of tegra_ehci_remove() calls usb_put_hcd(hcd) first and then iounmap(hcd->regs). usb_put_hcd() implementation calls hcd_release() which frees up memory allocated for hcd. As iounmap is trying to unmap hcd->regs, after hcd getting freed up, warning messages were observed during unload of USB. Hence fixing it. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-10usb: host: mips: sead3: Update for EHCI register structure.Steven J. Hill1-1/+1
One line fix after 'struct ehci_regs' definition was changed in commit a46af4ebf9ffec35eea0390e89935197b833dc61 (USB: EHCI: define extension registers like normal ones). Signed-off-by: Steven J. Hill <sjhill@mips.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-10usb: renesas_usbhs: fixup resume method for autonomy modeKuninori Morimoto1-3/+3
If renesas_usbhs is probed as autonomy mode, phy reset should be called after power resumed, and manual cold-plug should be called with slight delay. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-10usb: renesas_usbhs: mod_host: add missing .bus_suspend/resumeKuninori Morimoto1-0/+8
suspend/resume will failed on renesas_usbhs without this patch. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>