aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)Author
2011-11-11usb/isp1760: Added missing call to usb_hcd_check_unlink_urb() during unlinkArvid Brodin
commit 17d3e145a4ad680b3d1b1c30d0696a5bbb2b65c4 upstream. Signed-off-by: Arvid Brodin <arvid.brodin@enea.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: EHCI: Fix test mode sequenceBoris Todorov
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>
2011-11-11QE/FHCI: fixed the CONTROL bugJerry Huang
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>
2011-11-11USB: option: add various ZTE device network interfaces to the blacklistDan Williams
commit c58a76cdd7ab5a945a44fd2d64f6faf40323f95b upstream. IDs found in the Windows driver's ZTEusbnet.inf file from the ZTE MF100 drivers (O2 UK). Also fixes the ZTE MF626 device since it really is distinct from the 4G Systems stick and apparently needs the net interface blacklisted too, while there's no indication (yet) that the 4G Systems stick does. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: option: add ZTE product 0x0037 to sendsetup blacklistDan Williams
commit eb05ce567a81c592c58f4bdb96eb91ce96661c30 upstream. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: option: convert Huawei K3765, K4505, K4605 reservered interface to ↵Dan Williams
blacklist commit 0d905fd5ece4ab65e8407c450077744e1c8f661b upstream. That's what the blacklist is for... Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: option: convert interface blacklisting to bitfieldsDan Williams
commit b4626c10928c13ee73b013dcbc23676333e79b59 upstream. It's cleaner than the array stuff, and we're about to add a bunch more blacklist entries. Second, there are devices that need both the sendsetup and the reserved interface blacklists, which the current code can't accommodate. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: ftdi_sio: Support TI/Luminary Micro Stellaris BD-ICDI BoardPeter Stuge
commit 3687f641307eeff6f7fe31a88dc39db88e89238b upstream. Some Stellaris evaluation kits have the JTAG/SWD FTDI chip onboard, and some, like EK-LM3S9B90, come with a separate In-Circuit Debugger Interface Board. The ICDI board can also be used stand-alone, for other boards and chips than the kit it came with. The ICDI has both old style 20-pin JTAG connector and new style JTAG/SWD 10-pin 1.27mm pitch connector. Tested with EK-LM3S9B90, where the BD-ICDI board is included. Signed-off-by: Peter Stuge <peter@stuge.se> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: ftdi_sio: add PID for Sony Ericsson UrbanHakan Kvist
commit 74bdf22b5c3858b06af46f19d05c23e76c40a3bb upstream. Add PID 0xfc8a, 0xfc8b for device Sony Ericsson Urban Signed-off-by: Hakan Kvist <hakan.kvist@sonyericsson.com> Signed-off-by: Oskar Andero <oskar.andero@sonyericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: pl2303: add id for SMART deviceEric Benoit
commit 598f0b703506da841d3459dc0c48506be14d1778 upstream. Add vendor and product ID for the SMART USB to serial adapter. These were meant to be used with their SMART Board whiteboards, but can be re-purposed for other tasks. Tested and working (at at least 9600 bps). Signed-off-by: Eric Benoit <eric@ecks.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: add quirk for Logitech C300 web camJon Levell
commit 5b253d88cc6c65a23cefc457a5a4ef139913c5fc upstream. My webcam is a Logitech C300 and I get "chipmunk"ed squeaky sound. The following trivial patch fixes it. Signed-off-by: Jon Levell <linuxusb@coralbark.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: add RESET_RESUME for webcams shown to be quirkyOliver Neukum
commit 2394d67e446bf616a0885167d5f0d397bdacfdfc upstream. The new runtime PM code has shown that many webcams suffer from a race condition that may crash them upon resume. Runtime PM is especially prone to show the problem because it retains power to the cameras at all times. However system suspension may also crash the devices and retain power to the devices. The only way to solve this problem without races is in usbcore with the RESET_RESUME quirk. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11usb: cdc-acm: Owen SI-30 supportDenis Pershin
commit 65e52f41fa944cef2e6d4222b8c54f46cc575214 upstream. here is the patch to support Owen SI-30 device. This is a pulse counter controller. http://www.owen.ru/en/catalog/93788515 usb-drivers output: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03eb ProdID=0030 Rev=01.01 C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm This patch is installed on my home system which receives data from this controller connected to cold water counter. Signed-off-by: Denis Pershin <dyp@perchine.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: pid_ns: ensure pid is not freed during kill_pid_info_as_uidSerge Hallyn
commit aec01c5895051849ed842dc5b8794017a7751f28 upstream. Alan Stern points out that after spin_unlock(&ps->lock) there is no guarantee that ps->pid won't be freed. Since kill_pid_info_as_uid() is called after the spin_unlock(), the pid passed to it must be pinned. Reported-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11usb/core/devio.c: Check for printer class specific requestMatthias Dellweg
commit 393cbb5151ecda9f9e14e3082d048dd27a1ff9f6 upstream. In the usb printer class specific request get_device_id the value of wIndex is (interface << 8 | altsetting) instead of just interface. This enables the detection of some printers with libusb. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthias Dellweg <2500@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: g_printer: fix bug in unregistrationFabian Godehardt
commit 8582d86143c690c68cc42f996def466a035bee34 upstream. The allocated chardevice region range is only 1 device but on unregister it currently tries to deregister 2. Found this while doing a insmod/rmmod/insmod/rm... of the module which seemed to eat major numbers. Signed-off-by: Fabian Godehardt <fg@emlix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: Fix runtime wakeup on OHCIMatthew Garrett
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>
2011-11-11USB: storage: Use normalized sense when emulating autosenseLuben Tuikov
commit e16da02fcdf1c5e824432f88abf42623dafdf191 upstream. This patch solves two things: 1) Enables autosense emulation code to correctly interpret descriptor format sense data, and 2) Fixes a bug whereby the autosense emulation code would overwrite descriptor format sense data with SENSE KEY HARDWARE ERROR in fixed format, to incorrectly look like this: Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex): Oct 21 14:11:07 localhost kernel: 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 Oct 21 14:11:07 localhost kernel: 00 4f 00 c2 00 50 Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11usbmon vs. tcpdump: fix dropped packet countJohannes Stezenbach
commit 236c448cb6e7f82096101e1ace4b77f8b38f82c8 upstream. Report the number of dropped packets instead of zero when using the binary usbmon interface with tcpdump. # tcpdump -i usbmon1 -w dump tcpdump: listening on usbmon1, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes ^C2155 packets captured 2155 packets received by filter 1019 packets dropped by kernel Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11xHCI: AMD isoc link TRB chain bit quirkAndiry Xu
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>
2011-11-11xhci-mem.c: Check for ring->first_seg != NULLKautuk Consul
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>
2011-11-11EHCI: workaround for MosChip controller bugAlan Stern
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>
2011-11-11EHCI : introduce a common ehci_setupMatthieu CASTET
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>
2011-11-11USB: qcserial: add device ID for "HP un2430 Mobile Broadband Module"Rigbert Hamisch
commit 1bfac90d1b8e63a4d44158c3445d8fda3fb6d5eb upstream. add device ID for "HP un2430 Mobile Broadband Module" Signed-off-by: Rigbert Hamisch <rigbert@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: qcserial: Add support for Sierra Wireless MC8355/Gobi 3000Richard Hartmann
commit 68c79e5756903229fa96826a2493c2265a3b395f upstream. Simple patch to make qcserial recognize the USB id of the Sierra Wireless MC8355 which is based on the Gobi 3000 chip. Both UMTS and GPS work fine. Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-11USB: for usb_autopm_get_interface_async -EINPROGRESS is not an errorJim Wylder
commit c5a48592d874ddef8c7880311581eccf0eb30c3b upstream. A return value of -EINPROGRESS from pm_runtime_get indicates that the device is already resuming due to a previous call. Internally, usb_autopm_get_interface_async doesn't treat this as an error and increments the usage count, but passes the error status along to the caller. The logical assumption of the caller is that any negative return value reflects the device not resuming and the pm_usage_cnt not being incremented. Since the usage count is being incremented and the device is resuming, return success (0) instead. Signed-off-by: James Wylder <james.wylder@motorola.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03usb/host/pci-quirks.c: correct annotation of `ehci_dmi_nohandoff_table'Arnaud Lacombe
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>
2011-10-03USB: PL2303: correctly handle baudrates above 115200Michal Sroczynski
commit 8d48fdf689fed2c73c493e5146d1463689246442 upstream. PL2303: correctly handle baudrates above 115200 Signed-off-by: Michal Sroczynski <msroczyn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03ehci: add pci quirk for Ordissimo and RM Slate 100 tooAnisse Astier
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>
2011-10-03ehci: refactor pci quirk to use standard dmi_check_system methodAnisse Astier
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>
2011-10-03USB: xhci: Set change bit when warm reset change is set.Sarah Sharp
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>
2011-10-03xhci: Handle zero-length isochronous packets.Sarah Sharp
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>
2011-10-03xhci: Remove TDs from TD lists when URBs are canceled.Sarah Sharp
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>
2011-10-03xhci: Fix failed enqueue in the middle of isoch TD.Sarah Sharp
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>
2011-10-03xhci: Fix memory leak during failed enqueue.Sarah Sharp
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>
2011-10-03xHCI: report USB2 port in resuming as suspendAndiry Xu
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>
2011-10-03xHCI: fix port U3 status check conditionAndiry Xu
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>
2011-10-03USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ↵Wang Zhi
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>
2011-10-03usb: musb: cppi: fix build errors due to DBG and missing musb variablePer Forlin
commit f847a79ab3c1faca3022061045cd22e4678c1b1c upstream. Replace DBG with dev_dbg and fix invalid access of musb->controller. With this patch cppi_dma builds successfully. Signed-off-by: Per Forlin <per.forlin@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03USB option driver K3765/K4505 avoid CDC_DATA interfaceAndrew Bird
commit 6118514e8749105334f46ccec6faf9a439be6cf9 upstream. Currently the Option driver avoids binding interface 1 on Huawei K3765 and K4505 broadband modems as it should be handled by the cdc_ether driver instead. This patch ensures we don't bind the interface 2 on those devices as that is CDC_DATA. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03USB: option: add YUGA device id to driverGavin.zhu
commit c6eb2d75ffcdfafa37ff010bf467de20d468ef79 upstream. Signed-off-by: Gavin.zhu <gavin.kx@qq.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03USB option driver add PID of Huawei Vodafone K4605Andrew Bird
commit 7e1805844da18a37e6d251d286f93c94b52d791e upstream. This patch adds the product ID of Huawei's Vodafone K4605 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by suitable network driver. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03USB option driver add PID of Huawei Vodafone K3806Andrew Bird
commit 0e69d75ccb2f091757b38d4d6a2ed739e06b615e upstream. This patch adds the product ID of Huawei's Vodafone K3806 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Alex Chiang <achiang@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-03usb: s5p-ehci: fix a NULL pointer deferenceYulgon Kim
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>
2011-10-03USB: ftdi_sio: add Calao reference board supportJean-Christophe PLAGNIOL-VILLARD
commit c96fbdd0ab97235f930ebf24b38fa42a2e3458cf upstream. Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and port 1 for the UART They use the same VID and PID as FTDI Chip but they program the manufacturer name in the eeprom So use this information to detect it Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Gregory Hermant <gregory.hermant@calao-systems.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-17USB: option driver: add PID for Vodafone-Huawei K4511Andrew Bird
commit 35e9e21fb30dc4452b33aed5cbf233743bffca40 upstream. This patch adds the product ID of Huawei's Vodafone K4511 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-17USB: option driver: add PID for Vodafone-Huawei K4510Andrew Bird
commit 0930bb46bbbb43afe3381ece2cb2f8a5bc3fb544 upstream. This patch adds the product ID of Huawei's Vodafone K4510 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-17USB: option driver: add PID for Vodafone-Huawei K3771Andrew Bird
commit e2949080792256d1c979aaf30ecd4cab42829f87 upstream. This patch adds the product ID of Huawei's Vodafone K3771 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-17USB: option driver: add PID for Vodafone-Huawei K3770Andrew Bird
commit 07b21fd83606263fe6f327b98774d51e13e502fd upstream. This patch adds the product ID of Huawei's Vodafone K3770 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-17USB: Serial: Added device ID for Qualcomm Modem in Sagemcom's HiLo3GVijay Chavan
commit e468561739fffb972d486b98f66c723936335136 upstream. A new device ID pair is added for Qualcomm Modem present in Sagemcom's HiLo3G module. Signed-off-by: Vijay Chavan <VijayChavan007@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>