aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/host
Commit message (Collapse)AuthorAgeFilesLines
...
| * xHCI: Clear PLC for USB2 root hub portsAndiry Xu2011-11-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6fd4562178508a0949c9fdecd8558d8b10d671bd upstream. When the link state changes, xHC will report a port status change event and set the PORT_PLC bit, for both USB3 and USB2 root hub ports. The PLC will be cleared by usbcore for USB3 root hub ports, but not for USB2 ports, because they do not report USB_PORT_STAT_C_LINK_STATE in wPortChange. Clear it for USB2 root hub ports in handle_port_status(). Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xHCI: test and clear RWC bitAndiry Xu2011-11-113-10/+20
| | | | | | | | | | | | | | | | | | | | | | commit d2f52c9e585bbb1a3c164e02b8dcd0d996c67353 upstream. Introduce xhci_test_and_clear_bit() to clear RWC bit in PORTSC register. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xhci: If no endpoints changed, don't issue BW command.Sarah Sharp2011-11-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2dc3753997f3c80ce8b950242ab9bb3fb936acfd upstream. Some alternate interface settings have no endpoints associated with them. This shows up in some USB webcams, particularly the Logitech HD 1080p, which uses the uvcvideo driver. If a driver switches between two alt settings with no endpoints, there is no need to issue a configure endpoint command, because there is no endpoint information to update. The only time a configure endpoint command with just the add slot flag set makes sense is when the driver is updating hub characteristics in the slot context. However, that code never calls xhci_check_bandwidth, so we should be safe not issuing a command if only the slot context add flag is set. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * USB: xHCI: prevent infinite loop when processing MSE eventAndiry Xu2011-11-111-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c2d7b49f42f50d7fc5cbfd195b785a128723fdf4 upstream. When a xHC host is unable to handle isochronous transfer in the interval, it reports a Missed Service Error event and skips some tds. Currently xhci driver handles MSE event in the following ways: 1. When encounter a MSE event, set ep->skip flag, update event ring dequeue pointer and return. 2. When encounter the next event on this ep, the driver will run the do-while loop, fetch td from ep's td_list to find the td corresponding to this event. All tds missed are marked as short transfer(-EXDEV). The do-while loop will end in two ways: 1. If the td pointed by the event trb is found; 2. If the ep ring's td_list is empty. However, if a buggy HW reports some unpredicted event (for example, an overrun event following a MSE event while the ep ring is actually not empty), the driver will never find the td, and it will loop until the td_list is empty. Unfortunately, the spinlock is dropped when give back a urb in the do-while loop. During the spinlock released period, the class driver may still submit urbs and add tds to the td_list. This may cause disaster, since the td_list will never be empty and the loop never ends, and the system hangs. To fix this, count the number of TDs on the ep ring before skipping TDs, and quit the loop when skipped that number of tds. This guarantees the do-while loop will end after certain number of cycles, and driver will not be trapped in an infinite loop. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * usb/isp1760: Added missing call to usb_hcd_check_unlink_urb() during unlinkArvid Brodin2011-11-111-0/+3
| | | | | | | | | | | | | | | | commit 17d3e145a4ad680b3d1b1c30d0696a5bbb2b65c4 upstream. Signed-off-by: Arvid Brodin <arvid.brodin@enea.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * USB: EHCI: Fix test mode sequenceBoris Todorov2011-11-111-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 77636c86a600b83de01719efad83567e46d7e8ce upstream. The sequence to put port in test mode is not complete. According EHCI specification all enabled ports must be put in suspend. Signed-off-by: Boris Todorov <boris.st.todorov@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * QE/FHCI: fixed the CONTROL bugJerry Huang2011-11-111-4/+15
| | | | | | | | | | | | | | | | | | | | | | commit 273d23574f9dacd9c63c80e7d63639a669aad441 upstream. For USB CONTROL transaction, when the data length is zero, the IN package is needed to finish this transaction in status stage. Signed-off-by: Jerry Huang <r66093@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * USB: Fix runtime wakeup on OHCIMatthew Garrett2011-11-111-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b upstream. At least some OHCI hardware (such as the MCP89) fails to flag any change in the host status register or the port status registers when receiving a remote wakeup while in D3 state. This results in the controller being resumed but no device state change being noticed, at which point the controller is put back to sleep again. Since there doesn't seem to be any reliable way to identify the state change, just unconditionally resume the hub. It'll be put back to sleep in the near future anyway if there are no active devices attached to it. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xHCI: AMD isoc link TRB chain bit quirkAndiry Xu2011-11-114-38/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7e393a834b41001174a8fb3ae3bc23a749467760 upstream. Setting the chain (CH) bit in the link TRB of isochronous transfer rings is required by AMD 0.96 xHCI host controller to successfully transverse multi-TRB TD that span through different memory segments. When a Missed Service Error event occurs, if the chain bit is not set in the link TRB and the host skips TDs which just across a link TRB, the host may falsely recognize the link TRB as a normal TRB. You can see this may cause big trouble - the host does not jump to the right address which is pointed by the link TRB, but continue fetching the memory which is after the link TRB address, which may not even belong to the host, and the result cannot be predicted. This causes some big problems. Without the former patch I sent: "xHCI: prevent infinite loop when processing MSE event", the system may hang. With that patch applied, system does not hang, but the host still access wrong memory address and isoc transfer will fail. With this patch, isochronous transfer works as expected. This patch should be applied to kernels as old as 2.6.36, which was when the first isochronous support was added for the xHCI host controller. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xhci-mem.c: Check for ring->first_seg != NULLKautuk Consul2011-11-111-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0e6c7f746ea99089fb3263709075c20485a479ae upstream. There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * EHCI: workaround for MosChip controller bugAlan Stern2011-11-115-8/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 68aa95d5d4de31c9348c1628ffa85c805305ebc5 upstream. This patch (as1489) works around a hardware bug in MosChip EHCI controllers. Evidently when one of these controllers increments the frame-index register, it changes the three low-order bits (the microframe counter) before changing the higher order bits (the frame counter). If the register is read at just the wrong time, the value obtained is too low by 8. When the appropriate quirk flag is set, we work around this problem by reading the frame-index register a second time if the first value's three low-order bits are all 0. This gives the hardware a chance to finish updating the register, yielding the correct value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jason N Pitt <jpitt@fhcrc.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * EHCI : introduce a common ehci_setupMatthieu CASTET2011-11-111-0/+29
| | | | | | | | | | | | | | | | | | | | | | commit 2093c6b49c8f1dc581d8953aca71297d4cace55e upstream. This allow to clean duplicated code in most of SOC driver. Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | usb: host: fix usb enumuration fails foreverdenis.choi2011-12-013-0/+9
| | | | | | | | | | | | | | | | | | | | | | Bugnizer no. 5609488 Sometimes AP-LTE usb enumuration fails forever OMAP detects a FS device at the end of port reset and hands off the port. This is not supported on OMAPs. Do not hand off if FS device is detected , and retry reset. Change-Id: I2e0fde35d60c03705b263f78eebb3574895fe5a1 Signed-off-by: denis.choi <denis.choi@samsung.com>
* | usb: ehci: Configure PHY-reset gpio_171Moiz Sonasath2011-12-012-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the ehci port resume-error work-around, we need to reset the USB 3320c Phy using a GPIO going into the RESETB pin of the Phy. With a Hardware modification on the tablet board of having GPIO 171 feed into the RESETB pin of the ehci phy, this patch configures GPIO_171 and uses it to do the Phy reset along with the soft-reset of the link(ehci) to recover from the resume-error. Change-Id: Ie0eb5c0c6ed34fefd9c64a0f72ab89a1398f6bae Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
* | HACK: usb: host: fix resume errordenis.choi2011-12-013-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | When the phy chip goes to suspend, Reduce DIR Signal Noise for stable suspend state. We set a resume error flag. So, this patch is applied for only resume error device. We tested this patch with our resume error device in a day, we can't meet a problem. Change-Id: I81dc254a71eb991cfcd50cd7797c521d5f964baf Signed-off-by: denis.choi <denis.choi@samsung.com>
* | usb: ehci: Add a delay after phy reset before using phy clockBenoit Goby2011-12-011-0/+1
| | | | | | | | | | | | | | | | Add a delay before switching back to using the phy clock, to leasve time for the phy clock to stabilize. Change-Id: Id666c410b99d07af2324166e71e48cc70e1b2f4a Signed-off-by: Benoit Goby <benoit@android.com>
* | usb: ehci: omap4xx: re-enumeration workaround refinedVikram Pandita2011-12-011-31/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If OMAP EHCI goes into a bad state while going to suspend, its observed that PORTSC.RESUME bit does not clear. The only resort we have is to soft reset the LINK(ehci) and also the PHY. Following is the sequence followed for a clean reset: 1. Switch the USB clock to internal mode (To avoid any PHY issue) 2. Perform Soft Reset of EHCI using UHH 3. Perform EHCI USCMD.HCR reset. 4. Perform Reset of the PHY. 5. Power the Port by configuring the EHCI Portsc. 6. Do below ULPI REG WRITE using INSNREG05 debug register a. Reset USB PHY - 0x85, 0x20 b. 0x84, 0x41 - Configure PHY FUNC-CTRL c. 0x87,0x18 - Configure PHY INTERFACE_CTRL d. 0x8A,0x66 - Configure PHY OTG_CTRL e. 0x84,0x45 - Configure PHY in Full Speed mode. Change-Id: I58b513e1b96d271ae73365d0ead10ddbabbafd82 Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* | usb: ehci: omap4xx: fix resume failureVikram Pandita2011-12-011-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It has been seen that there is noise during the 3ms no activity period on the ULPI lines. This causes sometimes the Port Resume not to work. So the SW workaround is to reset the EHCI and PHY and restart the RESUME signalling. By resetting the EHCI, the state m/c is in good state and RESUME will again work. If for some reason, RESUME did not work first time, then resort to a full re-enumeration. Change-Id: I02eb2552a890f67027f1eb99b756fdae32a9f02d Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* | HACK: ehci recovery from port resume failureVikram Pandita2011-12-011-0/+49
| | | | | | | | | | | | | | | | | | This is giving some error-recovery now on the failing device. This patch is not for merge yet Change-Id: I279af9a27220f45e987448f9247393e686df65a0 Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
* | HACK: fix ehci suspend/resume failureAnand Gadiyar2011-12-011-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Its observed with some PHY, the 60Mhz clock gets cut too soon for OMAP EHCI, leaving OMAP-EHCI in a bad state. So on starting port suspend, make sure the 60Mhz clock to EHCI is kept alive using an internal clock, so that EHCi can cleanly transition its hw state machine on a port suspend. Its not proven if this is the issue hit on USB3333, but the symptoms look very similar. NOTE: This is core linux file. The right fix is to re-implement the function for ehci-omap and put the fix there. Change-Id: I6f9bd7dbc2c228d882a626a8d41541b8a64d5d8a Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* | usb: ehci: remove the 1st wmb in qh_append_tdsMing Lei2011-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to ehci spec 4.10.2, Advance Queue If the fetched qTD has its Active bit set to a zero, the host controller aborts the queue advance and follows the queue head's horizontal pointer to the next schedule data structure. the 'qtd' will be linked into qh hardware queue after the line below *dummy = *qtd; is executed and observed by EHCI HC, but EHCI HC won't have chance to fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the line below dummy->hw_token = token; #set Active bit here is executed by CPU and observed by EHCI HC. There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st wmb is not needed and can be removed. Change-Id: I6347afac07bb940ffd36acbf15f3a84b8663b5c0 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> (cherry picked from commit 41f05dedeabb0e2cb03734de383db3f0ddecf9e0)
* | usb: ehci: only prepare zero packet for out transfer if requiredMing Lei2011-12-011-2/+3
| | | | | | | | | | | | | | | | | | | | | | Obviously, ZLP is only required for transfer of OUT direction, so just take same policy with UHCI for ZLP packet. Change-Id: I7bbc05117829b69f14f7909129afe24fe0f3b434 Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> (cherry picked from commit 9a971dda8208e0982094f29ef34bd190f2a081bd)
* | usb: ehci: remove wmb in qh_updateMing Lei2011-12-011-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qh_refresh is always called when the qh is idle and has not been linked into hardware queue, so EHCI will not access overlay of the qh at this time. Just before linking qh into hardware queue, there has already one wmb to order writing qh descriptor and writing dma address of the qh into hardware queue, so HC can always see up-to-date qh descriptor once the qh is fetched with its dma address by EHCI. Change-Id: I1c11a39d6d8a5f54d5b65cc2358895c9d2e13ac0 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> (cherry picked from commit 0412560e18b4330366653819c0c5e73a743ff7e8)
* | Revert "usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP" Switch to ↵Moiz Sonasath2011-12-012-35/+0
| | | | | | | | | | | | | | | | | | | | upstream accepted solution. This reverts commit 95cf7a199cf8bcd6647c3b90efb78614157bf766. Change-Id: Id55c6e6a6c8c2df2d151771f73f161f8110eb3fd Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
* | usb: ehci: report Data Buffer Error in debug modeVikram Pandita2011-12-011-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Data Buffer Error as per spec section 4.15.1.1.2 results when there is Underrun or Overrun condition. This error is considered non-fatal and never gets reported. Its a very good indication on things going wrong at system level, like running memory at much slower speed. This is a good error to flag allowing system level corrections. An issue was found with OMAP4460 board where DDR had to be run at full speed and this logging helped. Change-Id: I444a3c7ba15dc6b18d4c7a9b0c057c5a344fee0f Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* | tuna: ehci: Fix bug in the ehci recover codeseelhyoung.choi2011-12-011-1/+2
| | | | | | | | | | | | | | | | Change the initiate place of count value under again tag not to make infinite loop in the while Change-Id: I6c0e6fb388015b1f08d87e650823247a326fe7df Signed-off-by: eelhyoung.choi <eelhyoung.choi@samsung.com>
* | usb: ehci-omap: remove jiffies dependency on upli functionsVikram Pandita2011-12-011-8/+6
| | | | | | | | | | | | | | | | | | | | | | Its seen that ulpi_write() function gets called with interrupts disabled. Jiffies are not getting incremented as the local cpu interrupts get disabled. So we cannot reliably depend on jiffies for a timeout. Use a simple retry counter with delay of 1 us between each retry. Change-Id: I086a8fb089f878dfcdcd7cc0f79947c06d118bf5 Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* | usb: ehci-omap: implement ulpi helpersVikram Pandita2011-12-011-0/+68
| | | | | | | | | | | | | | | | Implement ULPI read/write helper functions. These get used in case of error handling to bypass standard LINK ULPI. Change-Id: I3d21143b2a152f5dce4c71c6299ee4dd8cf58b74 Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* | usb: host: omap: add tput constrain on bus_resumeBenoit Goby2011-11-221-0/+9
| | | | | | | | | | | | | | | | OPP50 for CORE is not supported when EHCI is active. Add a constrain to force OPP100 when EHCI bus is resumed. Change-Id: I1b4227993962cc26d4d72b56aba2c396d4d3e6f5 Signed-off-by: Benoit Goby <benoit@android.com>
* | USB: EHCI: Fix compilation warningMoiz Sonasath2011-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | This patch fixes the following compilation warning: drivers/usb/host/ehci-hub.c:1144: warning: 'ehci_relinquish_port' defined but not used drivers/usb/host/ehci-hub.c:1153: warning: 'ehci_port_handed_over' defined but not used Change-Id: I1e354a23e9402539abde43b1d219e9f831415e54 Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
* | Merge branch 'linux-omap-3.0' into android-omap-3.0Colin Cross2011-10-276-53/+141
|\ \
| * \ Merge commit 'v3.0.8' into linux-omap-3.0Colin Cross2011-10-276-53/+141
| |\ \ | | |/ | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/tty/serial/omap-serial.c drivers/usb/musb/musb_gadget.c sound/soc/omap/omap-mcbsp.c Change-Id: Ic31b7266dda3ac8483f737272874ebf4725b5fe3
| | * usb/host/pci-quirks.c: correct annotation of `ehci_dmi_nohandoff_table'Arnaud Lacombe2011-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a7e6401e19aa54924ab11ee548afaad0a55ffdc6 upstream. ehci_bios_handoff() is marked __devinit, `ehci_dmi_nohandoff_table' should be marked __devinitconst, not __initconst. This fixes the following section mismatch: WARNING: vmlinux.o(.devinit.text+0x4f08): Section mismatch in reference from the function ehci_bios_handoff() to the variable .init.rodata:ehci_dmi_nohandoff_table The function __devinit ehci_bios_handoff() references a variable __initconst ehci_dmi_nohandoff_table. If ehci_dmi_nohandoff_table is only used by ehci_bios_handoff then annotate ehci_dmi_nohandoff_table with a matching annotation. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Arnaud Lacombe <lacombar@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * ehci: add pci quirk for Ordissimo and RM Slate 100 tooAnisse Astier2011-10-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0c42a4e84502533ec40544324debe2a62836ae11 upstream. Add another variant of the Pegatron tablet used by Ordissimo, and apparently RM Slate 100, to the list of models that should skip the negociation for the handoff of the EHCI controller. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * ehci: refactor pci quirk to use standard dmi_check_system methodAnisse Astier2011-10-031-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 03c75362181b0b1d6a330e7cf8def10ba988dfbe upstream. In commit 3610ea5397b80822e417aaa0e706fd803fb05680 (ehci: workaround for pci quirk timeout on ExoPC), a workaround was added to skip the negociation for the handoff of the EHCI controller. Refactor the DMI detection code to use standard dmi_check_system function. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Set change bit when warm reset change is set.Sarah Sharp2011-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 44f4c3ed60fb21e1d2dd98304390ac121e6c7c6d upstream. Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point xHCI host controller will report a link state change with the state set to "SS.Inactive". This causes the xHCI host controller to issue a warm port reset, which doesn't finish before the USB core times out while waiting for it to complete. When the warm port reset does complete, and the xHC gives back a port status change event, the xHCI driver kicks khubd. However, it fails to set the bit indicating there is a change event for that port because the logic in xhci-hub.c doesn't check for the warm port reset bit. After that, the warm port status change bit is never cleared by the USB core, and the xHC stops reporting port status change bits. (The xHCI spec says it shouldn't report more port events until all change bits are cleared.) This means any port changes when a new device is connected will never be reported, and the port will seem "dead" until the xHCI driver is unloaded and reloaded, or the computer is rebooted. Fix this by making the xHCI driver set the port change bit when a warm port reset change bit is set. A better solution would be to make the USB core handle warm port reset in differently, merging the current code with the standard port reset code that does an incremental backoff on the timeout, and tries to complete the port reset two more times before giving up. That more complicated fix will be merged next window, and this fix will be backported to stable. This should be backported to kernels as old as 3.0, since that was the first kernel with commit a11496ebf375 ("xHCI: warm reset support"). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | * xhci: Handle zero-length isochronous packets.Sarah Sharp2011-10-031-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 48df4a6fd8c40c0bbcbca2044f5f2bc75dcf6db1 upstream. For a long time, the xHCI driver has had this note: /* FIXME: Ignoring zero-length packets, can those happen? */ It turns out that, yes, there are drivers that need to queue zero-length transfers for isochronous OUT transfers. Without this patch, users will see kernel hang messages when a driver attempts to enqueue an isochronous URB with a zero length transfer (because count_isoc_trbs_needed will return zero for that TD, xhci_td->last_trb will never be set, and updating the dequeue pointer will cause an infinite loop). Matěj ran into this issue when using an NI Audio4DJ USB soundcard with the snd-usb-caiaq driver. See https://bugzilla.kernel.org/show_bug.cgi?id=40702 Fix count_isoc_trbs_needed() to return 1 for zero-length transfers (thanks Alan on the math help). Update the various TRB field calculations to deal with zero-length transfers. We're still transferring one packet with a zero-length data payload, so the total_packet_count should be 1. The Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC) fields should be set to zero. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Matěj Laitl <matej@laitl.cz> Cc: Daniel Mack <zonque@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * xhci: Remove TDs from TD lists when URBs are canceled.Sarah Sharp2011-10-032-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 585df1d90cb07a02ca6c7a7d339e56e46d50dafb upstream. When a driver tries to cancel an URB, and the host controller is dying, xhci_urb_dequeue will giveback the URB without removing the xhci_tds that comprise that URB from the td_list or the cancelled_td_list. This can cause a race condition between the driver calling URB dequeue and the stop endpoint command watchdog timer. If the timer fires on a dying host, and a driver attempts to resubmit while the watchdog timer has dropped the xhci->lock to giveback a cancelled URB, URBs may be given back by the xhci_urb_dequeue() function. At that point, the URB's priv pointer will be freed and set to NULL, but the TDs will remain on the td_list. This will cause an oops in xhci_giveback_urb_in_irq() when the watchdog timer attempts to loop through the endpoints' td_lists, giving back killed URBs. Make sure that xhci_urb_dequeue() removes TDs from the TD lists and canceled TD lists before it gives back the URB. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * xhci: Fix failed enqueue in the middle of isoch TD.Sarah Sharp2011-10-031-6/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 522989a27c7badb608155b1f1dea3487ed431f74 upstream. When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare() will ensure that there is enough room on the transfer rings for all of the isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is enqueueing individual isoc TDs, the prepare_transfer() function can fail if the endpoint state has changed to disabled, error, or some other unknown state. With the current code, if Nth TD (not the first TD) fails, the ring is left in a sorry state. The partially enqueued TDs are left on the ring, and the first TRB of the TD is not given back to the hardware. The enqueue pointer is left on the TRB after the last successfully enqueued TD. This means the ring is basically useless. Any new transfers will be enqueued after the failed TDs, which the hardware will never read because the cycle bit indicates it does not own them. The ring will fill up with untransferred TDs, and the endpoint will be basically unusable. The untransferred TDs will also remain on the TD list. Since the td_list is a FIFO, this basically means the ring handler will be waiting on TDs that will never be completed (or worse, dereference memory that doesn't exist any more). Change the code to clean up the isochronous ring after a failed transfer. If the first TD failed, simply return and allow the xhci_urb_enqueue function to free the urb_priv. If the Nth TD failed, first remove the TDs from the td_list. Then convert the TRBs that were enqueued into No-op TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any link TRBs in the middle or between TDs), but leave the cycle bit of the first TRB (which will show software-owned) intact. Then move the ring enqueue pointer back to the first TRB and make sure to change the xhci_ring's cycle state to what is appropriate for that ring segment. This ensures that the No-op TRBs will be overwritten by subsequent TDs, and the hardware will not start executing random TRBs because the cycle bit was left as hardware-owned. This bug is unlikely to be hit, but it was something I noticed while tracking down the watchdog timer issue. I verified that the fix works by injecting some errors on the 250th isochronous URB queued, although I could not verify that the ring is in the correct state because uvcvideo refused to talk to the device after the first usb_submit_urb() failed. Ring debugging shows that the ring looks correct, however. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * xhci: Fix memory leak during failed enqueue.Sarah Sharp2011-10-032-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d13565c12828ce0cd2a3862bf6260164a0653352 upstream. When the isochronous transfer support was introduced, and the xHCI driver switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of memory leaks were introduced into the URB enqueue function in its error handling paths. xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing the control endpoint's max packet size fails or the bulk endpoint is in the middle of allocating or deallocating streams. xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint types' enqueue functions fail. Instead, it expects those functions to free urb_priv if an error occurs. However, the bulk, control, and interrupt enqueue functions do not free urb_priv if the endpoint ring is NULL. It will, however, get freed if prepare_transfer() fails in those enqueue functions. Several of the error paths in the isochronous endpoint enqueue function also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv if prepare_ring() indicates there is not enough room for all the isochronous TDs in this URB. If individual isochronous TDs fail to be queued (perhaps due to an endpoint state change), urb_priv is also leaked. This argues that the freeing of urb_priv should be done in the function that allocated it, xhci_urb_enqueue. This patch looks rather ugly, but refactoring the code will have to wait because this patch needs to be backported to stable kernels. This patch should be backported to kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * xHCI: report USB2 port in resuming as suspendAndiry Xu2011-10-031-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8a8ff2f9399b23b968901f585ccb5a70a537c5ae upstream. When a USB2 port initiate a remote wakeup, software shall ensure that resume is signaled for at least 20ms, and then write '0' to the PLS field. According to this, xhci driver do the following things: 1. When receive a remote wakeup event in irq_handler, set the resume_done value as jiffies + 20ms, and modify rh_timer to poll root hub status at that time; 2. When receive a GetPortStatus request, if the jiffies is after the resume_done value, clear the resume signal and resume_done. However, if usb_port_resume() is called before the rh_timer triggered, it will indicate the port as Suspend Cleared and skip the clear resume signal part. The device will fail the usb_get_status request in finish_port_resume(), and usbcore will try a reset-resume instead. Device will work OK after reset-resume, but resume_done value is not cleared in this case, and xhci_bus_suspend() will fail because when it finds a non-zero resume_done value, it will regard the port as resuming and return -EBUSY. This causes issue on some platforms that the system fail to suspend after remote wakeup from suspend by USB2 devices connected to xHCI port. To fix this issue, report the port status as suspend if the resume is signaling less that 20ms, and usb_port_resume() will wait 25ms and check port status again, so xHCI driver can clear the resume signaling and resume_done value. This should be backported to kernels as old as 2.6.37. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * xHCI: fix port U3 status check conditionAndiry Xu2011-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5ac04bf190e6f8b17238aef179ebd7f2bdfec919 upstream. Fix the port U3 status check when Clear PORT_SUSPEND Feature. The port status should be masked with PORT_PLS_MASK to check if it's in U3 state. This should be backported to kernels as old as 2.6.37. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ↵Wang Zhi2011-10-031-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ehci_bus_resume(). commit d0f2fb2500b1c5fe4967eb45d8c9bc758d7aef80 upstream. From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss the action of clearing PORT_RESUME. This will cause unexpected long resume signal on USB bus. Signed-off-by: Wang Zhi <zhi.wang@windriver.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * usb: s5p-ehci: fix a NULL pointer deferenceYulgon Kim2011-10-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e5d3d4463fb30998385f9e78ab3c7f63b5813000 upstream. This patch fixes a NULL pointer deference. A NULL pointer dereference happens since s5p_ehci->hcd field is not initialized yet in probe function. [jg1.han@samsung.com: edit commit message] Signed-off-by: Yulgon Kim <yulgon.kim@samsung.com> Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * xhci: Don't submit commands or URBs to halted hosts.Sarah Sharp2011-08-171-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7bd89b4017f46a9b92853940fd9771319acb578a upstream. Commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called" caused a bit of an issue when the xHCI host controller driver is unloaded. It changed the USB core to remove all endpoints when a USB device is disabled. When the driver is unloaded, it will remove the SuperSpeed split root hub, which will disable all devices under that roothub and then halt the host controller. When the second High Speed split roothub is removed, the USB core will attempt to disable the endpoints, which will submit a Configure Endpoint command to a halted host controller. The command will eventually time out, but it makes the xHCI driver unload take *minutes* if there are a couple of USB 1.1/2.0 devices attached. We must halt the host controller when the SuperSpeed roothub is removed, because we can't allow any interrupts from things like port status changes. Make several different functions not submit commands or URBs to the host controller when the host is halted, by adding a check in xhci_check_args(). xhci_check_args() is used by these functions: xhci.c-int xhci_urb_enqueue() xhci.c-int xhci_drop_endpoint() xhci.c-int xhci_add_endpoint() xhci.c-int xhci_check_bandwidth() xhci.c-void xhci_reset_bandwidth() xhci.c-static int xhci_check_streams_endpoint() xhci.c-int xhci_discover_or_reset_device() It's also used by xhci_free_dev(). However, we have to take special care in that case, because we want the device memory to be freed if the host controller is halted. This patch should be backported to the 2.6.39 and 3.0 kernel. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: fix OS want to own HCJiSheng Zhang2011-08-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6768458b17f9bf48a4c3a34e49b20344091b5f7e upstream. Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC. This patch should be backported to kernels as far back as 2.6.31. Signed-off-by: JiSheng Zhang <jszhang3@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | | Merge branch 'linux-omap-3.0' into android-omap-3.0Iliyan Malchev2011-10-211-0/+5
|\ \ \ | |/ /
| * | usb: host: ehci: add wmb after modifying qtd pointerColin Cross2011-10-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A wmb is required after modify the hw_next pointer of a qtd before freeing the old qtd it was pointing to. Otherwise, the new address may be stuck in a write buffer, and the old address still visible to the host controller. Change-Id: I390f96e62eab9bdd7a9a9596f51a637455ee3fdf Signed-off-by: Colin Cross <ccross@android.com>
* | | Merge branch 'android-3.0' into android-omap-3.0Iliyan Malchev2011-09-062-0/+35
|\ \ \ | |/ / |/| |
| * | usb: ehci: make HC see up-to-date qh/qtd descriptor ASAPMing Lei2011-09-062-0/+35
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the helper of ehci_sync_mem to flush qtd/qh into memory immediately on some ARM, so that HC can see the up-to-date qtd/qh descriptor asap. This patch fixs one performance bug on ARM Cortex A9 dual core platform, which has been reported on quite a few ARM machines (OMAP4, Tegra 2, snowball...), see details from link of https://bugs.launchpad.net/bugs/709245. The patch has been tested ok on OMAP4 panda A1 board, and the performance of 'dd' over usb mass storage can be increased from 4~5MB/sec to 14~16MB/sec after applying this patch. Change-Id: I7994c58a1001c7f46f13e09420328a3916bbfcef Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
generated by cgit v1.1 at 2025-03-14 03:23:05 +0000