aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/host (follow)
AgeCommit message (Collapse)AuthorFilesLines
2011-11-18OHCI: final fix for NVIDIA problems (I hope)Alan Stern4-64/+28
Problems with NVIDIA's OHCI host controllers persist. After looking carefully through the spec, I finally realized that when a controller is reset it then automatically goes into a SUSPEND state in which it is completely quiescent (no DMA and no IRQs) and from which it will not awaken until the system puts it into the OPERATIONAL state. Therefore there's no need to worry about controllers being in the RESET state for extended periods, or remaining in the OPERATIONAL state during system shutdown. The proper action for device initialization is to put the controller into the RESET state (if it's not there already) and then to issue a software reset. Similarly, the proper action for device shutdown is simply to do a software reset. This patch (as1499) implements such an approach. It simplifies initialization and shutdown, and allows the NVIDIA shutdown-quirk code to be removed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com> Tested-by: Arno Augustin <Arno.Augustin@web.de> Cc: stable <stable@vger.kernel.org> [after tested in 3.2 for a while] Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-18usb: Netlogic: Fix HC_LENGTH call in ehci-xls.cJayachandran C1-1/+1
Fix compile error, HC_LENGTH now takes two parameters and ehci needs to be passed as the first parameter. Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-14USB: at91: at91-ohci: fix set/get powerJean-Christophe PLAGNIOL-VILLARD1-0/+6
in commit aa6e52a35 we introduce the support of overcurrent notification but the set and get of the power without checking if the gpio is valid or not Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-14USB: EHCI: fix HUB TT scheduling issue with iso transferThomas Poussevin1-5/+10
The current TT scheduling doesn't allow to play and then record on a full-speed device connected to a high speed hub. The IN iso stream can only start on the first uframe (0-2 for a 165 us) because of CSPLIT transactions. For the OUT iso stream there no such restriction. uframe 0-5 are possible. The idea of this patch is that the first uframe are precious (for IN TT iso stream) and we should allocate the last uframes first if possible. For that we reverse the order of uframe allocation (last uframe first). Here an example : hid interrupt stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ---------------------------------------------------------------------- iso OUT stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 | ---------------------------------------------------------------------- There no place for iso IN stream (uframe 0-2 are used) and we got "cannot submit datapipe for urb 0, error -28: not enough bandwidth" error. With the patch this become. iso OUT stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 39 | 0 | 0 | ---------------------------------------------------------------------- iso IN stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 39 | 0 | 0 | ---------------------------------------------------------------------- Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com> Signed-off-by: Thomas Poussevin <thomas.poussevin@parrot.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-14USB: XHCI: resume root hubs when the controller resumesAlan Stern1-15/+14
This patch (as1494) fixes a problem in xhci-hcd's resume routine. When the controller is runtime-resumed, this can only mean that one of the two root hubs has made a wakeup request and therefore needs to be resumed as well. Rather than try to determine which root hub requires attention (which might be difficult in the case where a new non-SuperSpeed device has been plugged in), the patch simply resumes both root hubs. Without this change, there is a race: The controller might be put back to sleep before it can activate its IRQ line, and the wakeup condition might never get handled. The patch also simplifies the logic in xhci_resume a little, combining some repeated flag settings into a single pair of statements. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@vger.kernel.org> Tested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-14USB: workaround for bug in old version of GCCAlan Stern1-4/+3
This patch (as1491) works around a bug in GCC-3.4.6, which is still supposed to be supported. The number of microseconds in the udelay() call in quirk_usb_disable_ehci() is fixed at 100, but the compiler doesn't understand this and generates a link-time error. So we replace the otherwise unused variable "delta" with a simple constant 100. This same pattern is already used in other delay loops in that source file. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Konrad Rzepecki <krzepecki@dentonet.pl> Tested-by: Konrad Rzepecki <krzepecki@dentonet.pl> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-14Merge branch 'for-usb-linus' of git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linusGreg Kroah-Hartman3-12/+11
* 'for-usb-linus' of ra.kernel.org:/pub/scm/linux/kernel/git/sarah/xhci: usb, xhci: Clear warm reset change event during init xhci: Set slot and ep0 flags for address command. usb, xhci: fix lockdep warning on endpoint timeout
2011-11-06Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linuxLinus Torvalds7-0/+7
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits) Revert "tracing: Include module.h in define_trace.h" irq: don't put module.h into irq.h for tracking irqgen modules. bluetooth: macroize two small inlines to avoid module.h ip_vs.h: fix implicit use of module_get/module_put from module.h nf_conntrack.h: fix up fallout from implicit moduleparam.h presence include: replace linux/module.h with "struct module" wherever possible include: convert various register fcns to macros to avoid include chaining crypto.h: remove unused crypto_tfm_alg_modname() inline uwb.h: fix implicit use of asm/page.h for PAGE_SIZE pm_runtime.h: explicitly requires notifier.h linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h miscdevice.h: fix up implicit use of lists and types stop_machine.h: fix implicit use of smp.h for smp_processor_id of: fix implicit use of errno.h in include/linux/of.h of_platform.h: delete needless include <linux/module.h> acpi: remove module.h include from platform/aclinux.h miscdevice.h: delete unnecessary inclusion of module.h device_cgroup.h: delete needless include <linux/module.h> net: sch_generic remove redundant use of <linux/module.h> net: inet_timewait_sock doesnt need <linux/module.h> ... Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in - drivers/media/dvb/frontends/dibx000_common.c - drivers/media/video/{mt9m111.c,ov6650.c} - drivers/mfd/ab3550-core.c - include/linux/dmaengine.h
2011-11-04xhci: Set slot and ep0 flags for address command.Sarah Sharp2-6/+4
Matt's AsMedia xHCI host controller was responding with a Context Error to an address device command after a configured device reset. Some sequence of events leads both the slot and endpoint zero add flags cleared to zero, which the AsMedia host doesn't like: [ 223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context: [ 223.701841] xhci_hcd 0000:03:00.0: @ffff880137b25000 (virt) @ffffc000 (dma) 0x000000 - drop flags [ 223.701843] xhci_hcd 0000:03:00.0: @ffff880137b25004 (virt) @ffffc004 (dma) 0x000000 - add flags [ 223.701846] xhci_hcd 0000:03:00.0: @ffff880137b25008 (virt) @ffffc008 (dma) 0x000000 - rsvd2[0] [ 223.701848] xhci_hcd 0000:03:00.0: @ffff880137b2500c (virt) @ffffc00c (dma) 0x000000 - rsvd2[1] [ 223.701850] xhci_hcd 0000:03:00.0: @ffff880137b25010 (virt) @ffffc010 (dma) 0x000000 - rsvd2[2] [ 223.701852] xhci_hcd 0000:03:00.0: @ffff880137b25014 (virt) @ffffc014 (dma) 0x000000 - rsvd2[3] [ 223.701854] xhci_hcd 0000:03:00.0: @ffff880137b25018 (virt) @ffffc018 (dma) 0x000000 - rsvd2[4] [ 223.701857] xhci_hcd 0000:03:00.0: @ffff880137b2501c (virt) @ffffc01c (dma) 0x000000 - rsvd2[5] [ 223.701858] xhci_hcd 0000:03:00.0: Slot Context: [ 223.701860] xhci_hcd 0000:03:00.0: @ffff880137b25020 (virt) @ffffc020 (dma) 0x8400000 - dev_info [ 223.701862] xhci_hcd 0000:03:00.0: @ffff880137b25024 (virt) @ffffc024 (dma) 0x010000 - dev_info2 [ 223.701864] xhci_hcd 0000:03:00.0: @ffff880137b25028 (virt) @ffffc028 (dma) 0x000000 - tt_info [ 223.701866] xhci_hcd 0000:03:00.0: @ffff880137b2502c (virt) @ffffc02c (dma) 0x000000 - dev_state [ 223.701869] xhci_hcd 0000:03:00.0: @ffff880137b25030 (virt) @ffffc030 (dma) 0x000000 - rsvd[0] [ 223.701871] xhci_hcd 0000:03:00.0: @ffff880137b25034 (virt) @ffffc034 (dma) 0x000000 - rsvd[1] [ 223.701873] xhci_hcd 0000:03:00.0: @ffff880137b25038 (virt) @ffffc038 (dma) 0x000000 - rsvd[2] [ 223.701875] xhci_hcd 0000:03:00.0: @ffff880137b2503c (virt) @ffffc03c (dma) 0x000000 - rsvd[3] [ 223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context: [ 223.701879] xhci_hcd 0000:03:00.0: @ffff880137b25040 (virt) @ffffc040 (dma) 0x000000 - ep_info [ 223.701881] xhci_hcd 0000:03:00.0: @ffff880137b25044 (virt) @ffffc044 (dma) 0x2000026 - ep_info2 [ 223.701883] xhci_hcd 0000:03:00.0: @ffff880137b25048 (virt) @ffffc048 (dma) 0xffffe8e0 - deq [ 223.701885] xhci_hcd 0000:03:00.0: @ffff880137b25050 (virt) @ffffc050 (dma) 0x000000 - tx_info [ 223.701887] xhci_hcd 0000:03:00.0: @ffff880137b25054 (virt) @ffffc054 (dma) 0x000000 - rsvd[0] [ 223.701889] xhci_hcd 0000:03:00.0: @ffff880137b25058 (virt) @ffffc058 (dma) 0x000000 - rsvd[1] [ 223.701892] xhci_hcd 0000:03:00.0: @ffff880137b2505c (virt) @ffffc05c (dma) 0x000000 - rsvd[2] ... [ 223.701927] xhci_hcd 0000:03:00.0: // Ding dong! [ 223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1. The xHCI spec says that both flags must be set to one for the Address Device command. When the device is first enumerated, xhci_setup_addressable_virt_dev() does set those flags. However, when the device is addressed after it has been reset in the configured state, xhci_setup_addressable_virt_dev() is not called, and xhci_copy_ep0_dequeue_into_input_ctx() is called instead. That function relies on the flags being set up by previous commands, which apparently isn't a good assumption. Move the setting of the flags into the common parent function. This should be queued for stable kernels as old as 2.6.35, since that was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Matt <mdm@iinet.net.au> Cc: stable@vger.kernel.org
2011-11-03Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds5-167/+360
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: (37 commits) MIPS: O32: Provide definition of registers ta0 .. ta3. MIPS: perf: Add Octeon support for hardware perf. MIPS: perf: Add support for 64-bit perf counters. MIPS: perf: Reorganize contents of perf support files. MIPS: perf: Cleanup formatting in arch/mips/kernel/perf_event.c MIPS: Add accessor macros for 64-bit performance counter registers. MIPS: Add probes for more Octeon II CPUs. MIPS: Add more CPU identifiers for Octeon II CPUs. MIPS: XLR, XLS: Add comment for smp setup MIPS: JZ4740: GPIO: Check correct IRQ in demux handler MIPS: JZ4740: GPIO: Simplify IRQ demuxer MIPS: JZ4740: Use generic irq chip MIPS: Alchemy: remove all CONFIG_SOC_AU1??? defines MIPS: Alchemy: kill au1xxx.h header MIPS: Alchemy: clean DMA code of CONFIG_SOC_AU1??? defines MIPS, IDE: Alchem, au1xxx-ide: Remove pb1200/db1200 header dep MIPS: Alchemy: Redo PCI as platform driver MIPS: Alchemy: more base address cleanup MIPS: Alchemy: rewrite USB platform setup. MIPS: Alchemy: abstract USB block control register access ... Fix up trivial conflicts in: arch/mips/alchemy/devboards/db1x00/platform.c drivers/ide/Kconfig drivers/mmc/host/au1xmmc.c drivers/video/Kconfig sound/mips/Kconfig
2011-11-02usb, xhci: fix lockdep warning on endpoint timeoutDon Zickus1-6/+7
While debugging a usb3 problem, I stumbled upon this lockdep warning. Oct 18 21:41:17 dhcp47-74 kernel: ================================= Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ] Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456 Oct 18 21:41:17 dhcp47-74 kernel: --------------------------------- Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at: Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a941>] __lock_acquire+0x781/0x1660 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa02299fa>] xhci_irq+0x3a/0x1960 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa022b351>] xhci_msi_irq+0x31/0x40 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810d2305>] handle_irq_event_percpu+0x85/0x320 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810d25e8>] handle_irq_event+0x48/0x70 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810d537d>] handle_edge_irq+0x6d/0x130 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810048c9>] handle_irq+0x49/0xa0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d56d>] do_IRQ+0x5d/0xe0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff815029b0>] ret_from_intr+0x0/0x13 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81388aca>] usb_set_device_state+0x8a/0x180 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8138f038>] usb_add_hcd+0x2b8/0x730 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa022ed7e>] xhci_pci_probe+0x9e/0xd4 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8127915f>] local_pci_probe+0x5f/0xd0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8127a569>] pci_device_probe+0x119/0x120 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81334473>] driver_probe_device+0xa3/0x2c0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8133473b>] __driver_attach+0xab/0xb0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8133373c>] bus_for_each_dev+0x6c/0xa0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813341fe>] driver_attach+0x1e/0x20 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81333b88>] bus_add_driver+0x1f8/0x2b0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81334df6>] driver_register+0x76/0x140 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8127a7c6>] __pci_register_driver+0x66/0xe0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa013c04a>] snd_timer_find+0x4a/0x70 [snd_timer] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa013c00e>] snd_timer_find+0xe/0x70 [snd_timer] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810001d3>] do_one_initcall+0x43/0x180 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810a9ed2>] sys_init_module+0x92/0x1f0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ab6b>] system_call_fastpath+0x16/0x1b Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984 Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last enabled at (631984): [<ffffffff81502720>] _raw_spin_unlock_irq+0x30/0x50 Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [<ffffffff81501c49>] _raw_spin_lock_irq+0x19/0x90 Oct 18 21:41:17 dhcp47-74 kernel: softirqs last enabled at (631980): [<ffffffff8105ff63>] _local_bh_enable+0x13/0x20 Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [<ffffffff8150ce6c>] call_softirq+0x1c/0x30 Oct 18 21:41:17 dhcp47-74 kernel: Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this: Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario: Oct 18 21:41:17 dhcp47-74 kernel: Oct 18 21:41:17 dhcp47-74 kernel: CPU0 Oct 18 21:41:17 dhcp47-74 kernel: ---- Oct 18 21:41:17 dhcp47-74 kernel: lock(&(&xhci->lock)->rlock); Oct 18 21:41:17 dhcp47-74 kernel: <Interrupt> Oct 18 21:41:17 dhcp47-74 kernel: lock(&(&xhci->lock)->rlock); Oct 18 21:41:17 dhcp47-74 kernel: Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK *** Oct 18 21:41:17 dhcp47-74 kernel: Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0: Oct 18 21:41:17 dhcp47-74 kernel: #0: (&ep->stop_cmd_timer){+.-...}, at: [<ffffffff8106abf2>] run_timer_softirq+0x162/0x570 Oct 18 21:41:17 dhcp47-74 kernel: Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace: Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0-rc4nmi+ #456 Oct 18 21:41:17 dhcp47-74 kernel: Call Trace: Oct 18 21:41:17 dhcp47-74 kernel: <IRQ> [<ffffffff81098ed7>] print_usage_bug+0x227/0x270 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810999c6>] mark_lock+0x346/0x410 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a7de>] __lock_acquire+0x61e/0x1660 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81099893>] ? mark_lock+0x213/0x410 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106ac9d>] run_timer_softirq+0x20d/0x570 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228960>] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd] Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810604d2>] __do_softirq+0xf2/0x3f0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81020edd>] ? lapic_next_event+0x1d/0x30 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81090d4e>] ? clockevents_program_event+0x5e/0x90 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ce6c>] call_softirq+0x1c/0x30 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8100484d>] do_softirq+0x8d/0xc0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8105ff35>] irq_exit+0xe5/0x100 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d65e>] smp_apic_timer_interrupt+0x6e/0x99 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150b6f0>] apic_timer_interrupt+0x70/0x80 Oct 18 21:41:17 dhcp47-74 kernel: <EOI> [<ffffffff81095d8d>] ? trace_hardirqs_off+0xd/0x10 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb76>] ? acpi_idle_enter_bm+0x227/0x25b Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb71>] ? acpi_idle_enter_bm+0x222/0x25b Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813eda63>] cpuidle_idle_call+0x103/0x290 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81002155>] cpu_idle+0xe5/0x160 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7f50>] rest_init+0xe0/0xf0 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7e70>] ? csum_partial_copy_generic+0x170/0x170 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8e23>] start_kernel+0x3fc/0x407 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8321>] x86_64_start_reservations+0x131/0x135 Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8412>] x86_64_start_kernel+0xed/0xf4 Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command. Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host. Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110 Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22 Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19) Basically what is happening is in xhci_stop_endpoint_command_watchdog() the xhci->lock is grabbed with just spin_lock. What lockdep deduces is that if an interrupt occurred while in this function it would deadlock with xhci_irq because that function also grabs the xhci->lock. Fixing it is trivial by using spin_lock_irqsave instead. This should be queued to stable kernels as far back as 2.6.33. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-11-01Merge branch 'next/devel' of git://git.linaro.org/people/arnd/arm-socLinus Torvalds1-19/+220
* 'next/devel' of git://git.linaro.org/people/arnd/arm-soc: (50 commits) ARM: tegra: update defconfig arm/tegra: Harmony: Configure PMC for low-level interrupts arm/tegra: device tree support for ventana board arm/tegra: add support for ventana pinmuxing arm/tegra: prepare Seaboard pinmux code for derived boards arm/tegra: pinmux: ioremap registers gpio/tegra: Convert to a platform device arm/tegra: Convert pinmux driver to a platform device arm/dt: Tegra: Add pinmux node to tegra20.dtsi arm/tegra: Prep boards for gpio/pinmux conversion to pdevs ARM: mx5: fix clock usage for suspend ARM i.MX entry-macro.S: remove now unused code ARM i.MX boards: use CONFIG_MULTI_IRQ_HANDLER ARM i.MX tzic: add handle_irq function ARM i.MX avic: add handle_irq function ARM: mx25: Add the missing IIM base definition ARM i.MX avic: convert to use generic irq chip mx31moboard: Add poweroff support ARM: mach-qong: Add watchdog support ARM: davinci: AM18x: Add wl1271/wlan support ... Fix up conflicts in: arch/arm/mach-at91/at91sam9g45.c arch/arm/mach-mx5/devices-imx53.h arch/arm/plat-mxc/include/mach/memory.h
2011-10-31usb: fix implicit usage of gfp.h in host/xhci-hub.cPaul Gortmaker1-0/+1
To fix this build error on ARM: drivers/usb/host/xhci-hub.c: In function 'xhci_stop_device': drivers/usb/host/xhci-hub.c:261: error: 'GFP_NOIO' undeclared (first use in this function) make[4]: *** [drivers/usb/host/xhci-hub.o] Error 1 Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-31usb: Add export.h for EXPORT_SYMBOL/THIS_MODULE where neededPaul Gortmaker2-0/+2
With module.h being implicitly everywhere via device.h, the absence of explicitly including something for EXPORT_SYMBOL went unnoticed. Since we are heading to fix things up and clean module.h from the device.h file, we need to explicitly include these files now. Use the lightweight version of the header that has just THIS_MODULE and EXPORT_SYMBOL variants. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-31usb: Add module.h to drivers/usb consumers who really use it.Paul Gortmaker4-0/+4
The situation up to this point meant that module.h was pretty much everywhere, regardless of whether you asked for it or not. We are fixing that, so give the USB folks who want it an actual include of it. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-31Merge branch 'depends/rmk/gpio' into next/develArnd Bergmann1-1/+1
Conflicts: arch/arm/mach-mxs/include/mach/gpio.h arch/arm/plat-mxc/include/mach/gpio.h Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2011-10-27Merge branch 'gpio' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-armLinus Torvalds1-1/+1
* 'gpio' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm: (43 commits) ARM: 7135/1: ep93xx: bring back missing <mach/gpio.h> ARM: 7104/1: plat-pxa: break out GPIO driver specifics ARM: 7103/1: plat-pxa: move PXA GPIO driver to GPIO subsystem ARM: 7042/3: mach-ep93xx: break out GPIO driver specifics ARM: 7101/1: arm/tegra: Replace <mach/gpio.h> with <mach/gpio-tegra.h> ARM: 7094/1: arm/tegra: Move EN_VDD_1V05_GPIO to board-harmony.h ARM: 7083/1: rewrite U300 GPIO to use gpiolib ARM: 7074/1: gpio: davinci: eliminate unused variable warnings ARM: 7063/1: Orion: gpio: add missing include of linux/types.h ARM: 7055/1: arm/tegra: mach/gpio.h: include linux/types.h to fix build ARM: 7054/1: arm/tegra: Delete custom gpio_to_irq, and irq_to_gpio ARM: 7053/1: gpio/tegra: Implement gpio_chip.to_irq ARM: 7052/1: gpio/tegra: Remove use of irq_to_gpio ARM: 7057/1: mach-pnx4008: rename GPIO header ARM: 7056/1: plat-nomadik: kill off <plat/gpio.h> ARM: 7050/1: mach-sa1100: delete irq_to_gpio() function ARM: 7049/1: mach-sa1100: move SA1100 GPIO driver to GPIO subsystem ARM: 7045/1: mach-lpc32xx: break out GPIO driver specifics ARM: 7044/1: mach-lpc32xx: move LPC32XX GPIO driver to GPIO subsystem ARM: 7043/1: mach-ixp2000: rename GPIO header ... Fix up trivial conflicts in arch/arm/mach-u300/Kconfig manually
2011-10-25Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds67-646/+3010
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (260 commits) usb: renesas_usbhs: fixup inconsistent return from usbhs_pkt_push() usb/isp1760: Allow to optionally trigger low-level chip reset via GPIOLIB. USB: gadget: midi: memory leak in f_midi_bind_config() USB: gadget: midi: fix range check in f_midi_out_open() QE/FHCI: fixed the CONTROL bug usb: renesas_usbhs: tidyup for smatch warnings USB: Fix USB Kconfig dependency problem on 85xx/QoirQ platforms EHCI: workaround for MosChip controller bug usb: gadget: file_storage: fix race on unloading USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers USB: ftdi_sio.c:Fill MSR fields of the ftdi async_icount structure USB: ftdi_sio.c: Fill LSR fields of the ftdi async_icount structure USB: ftdi_sio.c:Fill TX field of the ftdi async_icount structure USB: ftdi_sio.c: Fill the RX field of the ftdi async_icount structure USB: ftdi_sio.c: Basic icount infrastructure for ftdi_sio usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF . USB: ftdi_sio: Support TI/Luminary Micro Stellaris BD-ICDI Board USB: Fix runtime wakeup on OHCI xHCI/USB: Make xHCI driver have a BOS descriptor. usb: gadget: add new usb gadget for ACM and mass storage ...
2011-10-24MIPS: Alchemy: remove all CONFIG_SOC_AU1??? definesManuel Lauss1-1/+1
Now that no driver any longer depends on the CONFIG_SOC_AU1??? symbols, it's time to get rid of them: Move some of the platform devices to the boards which can use them, Rename a few (unused) constants in the header, Replace them with MIPS_ALCHEMY in the various Kconfig files. Finally delete them altogether from the Alchemy Kconfig file. Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com> To: Linux-MIPS <linux-mips@linux-mips.org> Patchwork: https://patchwork.linux-mips.org/patch/2707/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2011-10-24MIPS: Alchemy: abstract USB block control register accessManuel Lauss4-166/+359
Alchemy chips have one or more registers which control access to the usb blocks as well as PHY configuration. I don't want the OHCI/EHCI glues to know about the different registers and bits; new code hides the gory details of USB configuration from them. Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com> To: Linux-MIPS <linux-mips@linux-mips.org> Cc: linux-usb@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Patchwork: https://patchwork.linux-mips.org/patch/2709/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> create mode 100644 drivers/usb/host/alchemy-common.c
2011-10-20Merge branch 'imx/devel' into next/develArnd Bergmann2-1/+20
2011-10-19usb/isp1760: Allow to optionally trigger low-level chip reset via GPIOLIB.Joachim Foerster3-15/+72
Properly triggering the reset wire is necessary with the ISP1761 used on Terasic DE4 Altera-FPGA boards using a NIOS2 processor, for example. This is an optional implementation for the OF binding only. The other bindings just pass an invalid GPIO to the isp1760_register() routine. Example, usage in DTS: gpios = <&pio_isp1761rst_0 0 1>; to point to a GPIO controller from within the ISP1761 node: GPIO 0, active low. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-18QE/FHCI: fixed the CONTROL bugJerry Huang1-4/+15
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> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-18EHCI: workaround for MosChip controller bugAlan Stern5-8/+49
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> CC: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-18usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF .Joachim Foerster1-4/+6
To be able to use the driver on other OF-aware architectures, too. And add necessary OF related #includes to fix compilation error. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-18USB: Fix runtime wakeup on OHCIMatthew Garrett1-4/+1
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: stable <stable@vger.kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-18xHCI/USB: Make xHCI driver have a BOS descriptor.Sarah Sharp1-0/+34
To add USB 3.0 link power management (LPM), we need to know what the U1 and U2 exit latencies are for the xHCI host controller. External USB 3.0 hubs report these values through the SuperSpeed Capabilities descriptor in the BOS descriptor. Make the USB 3.0 roothub for the xHCI host behave like an external hub and return the BOS descriptors. The U1 and U2 exit latencies will vary across each host controller, so we need to dynamically fill those values in by reading the exit latencies out of the xHC registers. Make the roothub code in the USB core handle hub_control() returning the length of the data copied. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-13usb: gadget: renesas_usbhs: add mod_host supportKuninori Morimoto1-0/+13
This is mod_host prototype support for renesas_usbhs driver. It doesn't support USB-Hub, and USB-DMAC for now. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2011-09-26USB: UHCI: improve comments and logic for root-hub suspendAlan Stern1-32/+34
This patch (as1488) improves the comments and logic in uhci-hcd's suspend routine. The existing comments are hard to understand and don't give a good idea of what's really going on. The question of whether EGSM (Enter Global Suspend Mode) and RD (enable Resume Detect interrupts) can be useful when they're not both set is difficult. The spec doesn't give any details on how they interact with system wakeup, although clearly they are meant to be used together. To be safe, the patch changes the subroutine so that neither bit gets set unless they both do. There shouldn't be any functional changes from this; only systems that are designed badly or broken in some way need to avoid using those bits. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/xhci: remove CONFIG_PCI in xhci.c's probe functionSebastian Andrzej Siewior4-9/+8
This removes the need of ifdefs within the init function and with it the headache about the correct clean without bus X but with bus/platform Y & Z. xhci-pci is only compiled if CONFIG_PCI is selected which can be de-selected now without trouble. For now the result is kinda useless because we have no other glue code. However, since nobody is using USB_ARCH_HAS_XHCI then it should not be an issue :) Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/xhci: move xhci_gen_setup() away from -pci.Sebastian Andrzej Siewior3-91/+91
xhci_gen_setup() is generic so it can be used to perform the bare xhci setup even on non-pci based platform. The typedef for the function pointer is moved into the headerfile Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/xhci: refactor xhci_pci_setup()Sebastian Andrzej Siewior1-27/+54
xhci_pci_setup() is split into three pieces: - xhci_gen_setup() The major remaining of xhci_pci_setup() is now containing the generic part of the xhci setup. It allocates the xhci struct, setup hcs_params? and friends, performs xhci_halt(), xhci_init and so one. It also obtains the quirks via a callback - xhci_pci_quirks() It checks the origin of the xhci core and sets core specific quirks. - xhci_pci_setup() PCI specific setup functions. Besides calling xhci_gen_setup() with xhci_pci_quirks() as an argument it performs PCI specific setup like obtaining the address of sbrn via a PCI config space. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/xhci: replace pci_*_consistent() with dma_*_coherent()Sebastian Andrzej Siewior1-19/+19
pci_*_consistent() calls dma_*_coherent() with GFP_ATOMIC and requires pci_dev struct. This is a preparion for later where we no longer have the pci struct around. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/xhci: hide MSI code behind PCI barsSebastian Andrzej Siewior1-62/+98
The MSI related fuctionality requires a few structs which are not available if CONFIG_PCI is not enabled. This is a prepartion to allow xhci be built without CONFIG_PCI set. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/xhci: group MSI interrupt registration into its own functionSebastian Andrzej Siewior1-28/+42
This patch moves the complete MSI/MSI-X/Legacy dance into its own function. There is however one difference: If the XHCI_BROKEN_MSI flag is set then we don't free and register the irq, we simply return. This is preparation for later PCI decouple. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26usb/host: introduce USB_ARCH_HAS_XHCIFelipe Balbi1-1/+1
to make it look like OHCI and EHCI, we introduce that symbol and USB_XHCI_HCD depend on that instead of PCI. [bigeasy@linutronix.de: wire up USB_ARCH_HAS_HCD] Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26xHCI: fix debug messageAndiry Xu1-1/+1
Fix the debug message in xhci_address_device(). 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-09-26xHCI: AMD isoc link TRB chain bit quirkAndiry Xu4-38/+51
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> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-26xHCI: set USB2 hardware LPMAndiry Xu4-1/+87
If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. 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-09-26xHCI: test USB2 software LPMAndiry Xu4-1/+211
This patch tests USB2 software LPM for a USB2 LPM-capable device. When a lpm-capable device is addressed, if the host also supports software LPM, apply a test by putting the device into L1 state and resume it to see if the device can do L1 suspend/resume successfully. If the device fails to enter L1 or resume from L1 state, it may not function normally and usbcore may disconnect and re-enumerate it. In this case, store the device's Vid and Pid information, make sure the host will not test LPM for it twice. The test result is per device/host. Some devices claim to be lpm-capable, but fail to enter L1 or resume. So the test is necessary. The xHCI 1.0 errata has modified the USB2.0 LPM implementation. It redefines the HIRD field to BESL, and adds another register Port Hardware LPM Control (PORTHLPMC). However, this should not affect the LPM behavior on xHC which does not implement 1.0 errata. USB2.0 LPM errata defines a new bit BESL in the device's USB 2.0 extension descriptor. If the device reports it uses BESL, driver should use BESL instead of HIRD for it. 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-09-26xHCI: Check host USB2 LPM capabilityAndiry Xu3-0/+27
Check the host's USB2 LPM capability. USB2 software LPM support is optional for xHCI 0.96 hosts. xHCI 1.0 hosts should support software LPM, and may support hardware LPM. 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-09-26xHCI: Clear PLC for USB2 root hub portsAndiry Xu1-0/+4
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>
2011-09-26xHCI: test and clear RWC bitAndiry Xu3-10/+20
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>
2011-09-26xHCI: set link stateAndiry Xu3-47/+33
Introduce xhci_set_link_state() to remove redundant codes. 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-09-26EHCI : introduce a common ehci_setupMatthieu CASTET1-0/+29
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> Cc: stable <stable@kernel.org> # fixes 3.1 build error Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-20xhci-mem.c: xhci_segment_free: No need for checking seg argumentKautuk Consul1-2/+0
The seg argument to xhci_segment_free is never passed as NULL, so no need to check for this in xhci_segment_free. 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-09-20xhci-mem.c: Check for ring->first_seg != NULLKautuk Consul1-10/+12
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> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-20xhci: USB 3.0 BW checking.Sarah Sharp2-5/+67
The Intel Panther Point xHCI host tracks SuperSpeed endpoints in a different way than USB 2.0/1.1 endpoints. The bandwidth interval tables are not used, and instead the bandwidth is calculated in a very simple way. Bandwidth for SuperSpeed endpoints is tracked individually in each direction, since each direction has the full USB 3.0 bandwidth available. 10% of the bus bandwidth is reserved for non-periodic transfers. This checking would be more complex if we had USB 3.0 LPM enabled, because an additional latency for isochronous ping times need to be taken into account. However, we don't have USB 3.0 LPM support in Linux yet. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-20xhci: Fix mult base in endpoint bandwidth info.Sarah Sharp2-5/+7
The "Mult" bits in the SuperSpeed Endpoint Companion Descriptor are zero-based, and the xHCI host controller wants them to be zero-based in the input context. However, for the bandwidth math, we want them to be one-based. Fix this. Fix the documentation about the endpoint bandwidth mult variable in the xhci.h file, which says it is zero-based. Also fix the documentation about num_packets, which is also one-based, not zero-based. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-20usb/xhci: ignore xhci version while checking for the link quirkSebastian Andrzej Siewior2-4/+2
instead of reading the xhci interface version each time _even_ if the quirk is not required, simply check if the quirk flag is set. This flag is only set of the module parameter is set and here is where I moved the version check to. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.