aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb
Commit message (Collapse)AuthorAge
* usb_serial: Fix oops when unexisting usb serial device is opened.Thadeu Lima de Souza Cascardo2009-06-25
| | | | | | | | | | | | | | | This commit 335f8514f200e63d689113d29cb7253a5c282967 has stopped properly checking if there is any usb serial associated with the tty in the close function. It happens the close function is called by releasing the terminal right after opening the device fails. As an example, open fails with a non-existing device, when probe has never been called, because the device has never been plugged. This is common in systems with static modules and no udev. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* acm: Fix oops when closing ACM tty device right after open has failed.Thadeu Lima de Souza Cascardo2009-06-25
| | | | | | | | | | | | | | | This commit 10077d4a6674f535abdbe25cdecb1202af7948f1 has stopped checking if there was a valid acm device associated to the tty, which is not true right after open fails and tty subsystem tries to close the device. As an example, open fails with a non-existing device, when probe has never been called, because the device has never been plugged. This is common in systems with static modules and no udev. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* acm: Return ENODEV instead of EINVAL when trying to open ACM device.Thadeu Lima de Souza Cascardo2009-06-25
| | | | | | | | | | | | | | | | This is required, otherwise a user will get a EINVAL while opening a non-existing device, instead of ENODEV. This is what I get with this patch applied now instead of an "Invalid argument". cascardo@vespa:~$ cat /dev/ttyACM0 cat: /dev/ttyACM0: No such device cascardo@vespa:~$ Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge commit 'origin/master' into nextBenjamin Herrenschmidt2009-06-17
|\
| * Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6Linus Torvalds2009-06-16
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (143 commits) USB: xhci depends on PCI. USB: xhci: Add Makefile, MAINTAINERS, and Kconfig entries. USB: xhci: Respect critical sections. USB: xHCI: Fix interrupt moderation. USB: xhci: Remove packed attribute from structures. usb; xhci: Fix TRB offset calculations. USB: xhci: replace if-elseif-else with switch-case USB: xhci: Make xhci-mem.c include linux/dmapool.h USB: xhci: drop spinlock in xhci_urb_enqueue() error path. USB: Change names of SuperSpeed ep companion descriptor structs. USB: xhci: Avoid compiler reordering in Link TRB giveback. USB: xhci: Clean up xhci_irq() function. USB: xhci: Avoid global namespace pollution. USB: xhci: Fix Link TRB handoff bit twiddling. USB: xhci: Fix register write order. USB: xhci: fix some compiler warnings in xhci.h USB: xhci: fix lots of compiler warnings. USB: xhci: use xhci_handle_event instead of handle_event USB: xhci: URB cancellation support. USB: xhci: Scatter gather list support for bulk transfers. ...
| | * USB: xhci depends on PCI.Paul Mundt2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While it looks like xhci was written with both PCI and non-PCI in mind, apparently only the former has seen any testing. xhci-mem.o can be "fixed" with a linux/dmapool.h include, but there are still parts of the code that make use of struct pci_dev directly. So, at least more work is needed before this can be turned on for non-PCI builds: CC drivers/usb/host/xhci-mem.o drivers/usb/host/xhci-mem.c: In function 'xhci_segment_alloc': drivers/usb/host/xhci-mem.c:45: error: implicit declaration of function 'dma_pool_alloc' drivers/usb/host/xhci-mem.c:45: warning: assignment makes pointer from integer without a cast drivers/usb/host/xhci-mem.c: In function 'xhci_segment_free': drivers/usb/host/xhci-mem.c:67: error: implicit declaration of function 'dma_pool_free' drivers/usb/host/xhci-mem.c: In function 'xhci_alloc_virt_device': drivers/usb/host/xhci-mem.c:239: warning: assignment makes pointer from integer without a cast drivers/usb/host/xhci-mem.c:248: warning: assignment makes pointer from integer without a cast drivers/usb/host/xhci-mem.c: In function 'xhci_mem_cleanup': drivers/usb/host/xhci-mem.c:578: error: implicit declaration of function 'dma_pool_destroy' drivers/usb/host/xhci-mem.c: In function 'xhci_mem_init': drivers/usb/host/xhci-mem.c:657: error: implicit declaration of function 'dma_pool_create' drivers/usb/host/xhci-mem.c:658: warning: assignment makes pointer from integer without a cast drivers/usb/host/xhci-mem.c:663: warning: assignment makes pointer from integer without a cast make[3]: *** [drivers/usb/host/xhci-mem.o] Error 1 CC drivers/usb/host/xhci-pci.o drivers/usb/host/xhci-pci.c: In function 'xhci_pci_reinit': drivers/usb/host/xhci-pci.c:39: error: implicit declaration of function 'pci_set_mwi' drivers/usb/host/xhci-pci.c: At top level: drivers/usb/host/xhci-pci.c:151: error: 'usb_hcd_pci_probe' undeclared here (not in a function) drivers/usb/host/xhci-pci.c:152: error: 'usb_hcd_pci_remove' undeclared here (not in a function) drivers/usb/host/xhci-pci.c:155: error: 'usb_hcd_pci_shutdown' undeclared here (not in a function) drivers/usb/host/xhci-pci.c:159: warning: function declaration isn't a prototype drivers/usb/host/xhci-pci.c:164: warning: function declaration isn't a prototype make[3]: *** [drivers/usb/host/xhci-pci.o] Error 1 Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Add Makefile, MAINTAINERS, and Kconfig entries.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add Makefile and Kconfig entries for the xHCI host controller driver. List Sarah Sharp as the maintainer for the xHCI driver. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Respect critical sections.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Narrow down time spent holding the xHCI spinlock so that it's only used to protect the xHCI rings, not as mutual exclusion. Stop allocating memory while holding the spinlock and calling xhci_alloc_virt_device() and xhci_endpoint_init(). The USB core should have locking in it to prevent device state to be manipulated by more than one kernel thread. E.g. you can't free a device while you're in the middle of setting a new configuration. So removing the locks from the sections where xhci_alloc_dev() and xhci_reset_bandwidth() touch xHCI's representation of the device should be OK. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xHCI: Fix interrupt moderation.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mask off the lower 16 bits of the interrupt control register, instead of masking off the upper 16 bits. The interrupt moderation interval field is the lower 16 bytes, and is set to 0x4000 (1ms) by default. The previous code was adding 40 us to the default value, instead of setting it to 40 us. This makes performance really bad. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Remove packed attribute from structures.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The packed attribute allows gcc to muck with the alignment of data structures, which may lead to byte-wise writes that break atomicity of writes. Packed should only be used when the compile may add undesired padding to the structure. Each element of the structure will be aligned by C based on its size and the size of the elements around it. E.g. a u64 would be aligned on an 8 byte boundary, the next u32 would be aligned on a four byte boundary, etc. Since most of the xHCI structures contain only u32 bit values, removing the packed attribute for them should be harmless. (A future patch will change some of the twin 32-bit address fields to one 64-bit field, but all those places have an even number of 32-bit fields before them, so the alignment should be correct.) Add BUILD_BUG_ON statements to check that the compiler doesn't add padding to the data structures that have a hardware-defined layout. While we're modifying the registers, change the name of intr_reg to xhci_intr_reg to avoid global conflicts. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * usb; xhci: Fix TRB offset calculations.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Greg KH introduced a bug into xhci_trb_virt_to_dma() when he changed the type of offset to dma_addr_t from unsigned int and dropped the casts to unsigned int around the virtual address pointer subtraction. trb and seg->trbs are both valid pointers to virtual addresses, so the compiler will mod the subtraction by the size of union trb (16 bytes). segment_offset is an unsigned long, which is guaranteed to be at least as big as a void *. Drop the void * casts in the first if statement because trb and seg->trbs are both pointers of the same type (pointers to union trb). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: replace if-elseif-else with switch-caseViral Mehta2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace if-elseif-else with switch-case to keep the code consistent which is semantically same Switch-case is used here, http://www.spinics.net/lists/linux-usb/msg17201.html Making consistent at other places in usb/core Also easier to read and maintain when USB4.0, 5.0, ... comes Signed-off-by: Viral Mehta <viral.mehta@einfochips.com> Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Make xhci-mem.c include linux/dmapool.hSarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xhci-mem.c includes calls to dma_pool_alloc() and other functions defined in linux/dmapool.h. Make sure to include that header file. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: drop spinlock in xhci_urb_enqueue() error path.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure the error path in xhci_urb_enqueue() releases the spinlock before it returns. Reported by Oliver in http://marc.info/?l=linux-usb&m=124091637311832&w=2 Reported-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Change names of SuperSpeed ep companion descriptor structs.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Differentiate between SuperSpeed endpoint companion descriptor and the wireless USB endpoint companion descriptor. Make all structure names for this descriptor have "ss" (SuperSpeed) in them. David Vrabel asked for this change in http://marc.info/?l=linux-usb&m=124091465109367&w=2 Reported-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Avoid compiler reordering in Link TRB giveback.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Force the compiler to write the cycle bit of the Link TRB last. This ensures that the hardware doesn't think it owns the Link TRB before we set the chain bit. Reported by Oliver in this thread: http://marc.info/?l=linux-usb&m=124091532410219&w=2 Reported-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Clean up xhci_irq() function.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop spinlock in xhci_irq() error path. This fixes the issue reported by Oliver Neukum on this thread: http://marc.info/?l=linux-usb&m=124090924401444&w=2 Remove unnecessary register read reported by Viral Mehta: http://marc.info/?l=linux-usb&m=124091326007398&w=2 Reported-by: Oliver Neukum <oliver@neukum.org> Reported-by: Viral Mehta <viral.mehta@einfochips.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Avoid global namespace pollution.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Fix Link TRB handoff bit twiddling.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure to preserve all bits *except* the TRB_CHAIN bit when giving a Link TRB to the hardware. We need to save things like TRB type and the toggle bit in the control dword. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Fix register write order.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 0.95 xHCI spec says that if the xHCI HW support 64-bit addressing, you must write the whole 64-bit address as one atomic operation, or write the low 32 bits, and then the high 32 bits. I had the register writes swapped in some places. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: fix some compiler warnings in xhci.hGreg Kroah-Hartman2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the warning: drivers/usb/host/xhci.h:1083: warning: passing argument 1 of ‘xhci_to_hcd’ discards qualifiers from pointer target type drivers/usb/host/xhci.h:1083: warning: passing argument 1 of ‘xhci_to_hcd’ discards qualifiers from pointer target type Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: fix lots of compiler warnings.Greg Kroah-Hartman2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: use xhci_handle_event instead of handle_eventStephen Rothwell2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The former is way to generic for a global symbol. Fixes this build error: drivers/usb/built-in.o: In function `.handle_event': (.text+0x67dd0): multiple definition of `.handle_event' drivers/pcmcia/built-in.o:(.text+0xcfcc): first defined here drivers/usb/built-in.o: In function `handle_event': (.opd+0x5bc8): multiple definition of `handle_event' drivers/pcmcia/built-in.o:(.opd+0xed0): first defined here Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: URB cancellation support.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add URB cancellation support to the xHCI host controller driver. This currently supports cancellation for endpoints that do not have streams enabled. An URB is represented by a number of Transaction Request Buffers (TRBs), that are chained together to make one (or more) Transaction Descriptors (TDs) on an endpoint ring. The ring is comprised of contiguous segments, linked together with Link TRBs (which may or may not be chained into a TD). To cancel an URB, we must stop the endpoint ring, make the hardware skip over the TDs in the URB (either by turning them into No-op TDs, or by moving the hardware's ring dequeue pointer past the last TRB in the last TD), and then restart the ring. There are times when we must drop the xHCI lock during this process, like when we need to complete cancelled URBs. We must ensure that additional URBs can be marked as cancelled, and that new URBs can be enqueued (since the URB completion handlers can do either). The new endpoint ring variables cancels_pending and state (which can only be modified while holding the xHCI lock) ensure that future cancellation and enqueueing do not interrupt any pending cancellation code. To facilitate cancellation, we must keep track of the starting ring segment, first TRB, and last TRB for each URB. We also need to keep track of the list of TDs that have been marked as cancelled, separate from the list of TDs that are queued for this endpoint. The new variables and cancellation list are stored in the xhci_td structure. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Scatter gather list support for bulk transfers.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for bulk URBs that pass scatter gather lists to xHCI. This allows xHCI to more efficiently enqueue these transfers, and allows the host controller to take advantage of USB 3.0 "bursts" for bulk endpoints. Use requested length to calculate the number of TRBs needed for a scatter gather list transfer, instead of using the number of sglist entries. The application can pass down a scatter gather list that is bigger than it needs for the requested transfer. Scatter gather entries can cross 64KB boundaries, so be careful to setup TRBs such that no buffer crosses a 64KB boundary. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Push scatter gather lists down to host controller drivers.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the original patch I created before David Vrabel posted a better patch (http://marc.info/?l=linux-usb&m=123377477209109&w=2) that does basically the same thing. This patch will get replaced with his (modified) patch later. Allow USB device drivers that use usb_sg_init() and usb_sg_wait() to push bulk endpoint scatter gather lists down to the host controller drivers. This allows host controller drivers to more efficiently enqueue these transfers, and allows the xHCI host controller to better take advantage of USB 3.0 "bursts" for bulk endpoints. This patch currently only enables scatter gather lists for bulk endpoints. Other endpoint types that use the usb_sg_* functions will not have their scatter gather lists pushed down to the host controller. For periodic endpoints, we want each scatterlist entry to be a separate transfer. Eventually, HCDs could parse these scatter-gather lists for periodic endpoints also. For now, we use the old code and call usb_submit_urb() for each scatterlist entry. The caller of usb_sg_init() can request that all bytes in the scatter gather list be transferred by passing in a length of zero. Handle that request for a bulk endpoint under xHCI by walking the scatter gather list and calculating the length. We could let the HCD handle a zero length in this case, but I'm not sure if the core layers in between will get confused by this. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Bulk transfer supportSarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow device drivers to submit URBs to bulk endpoints on devices under an xHCI host controller. Share code between the control and bulk enqueueing functions when it makes sense. To get the best performance out of bulk transfers, SuperSpeed devices must have the bMaxBurst size copied from their endpoint companion controller into the xHCI device context. This allows the host controller to "burst" up to 16 packets before it has to wait for the device to acknowledge the first packet. The buffers in Transfer Request Blocks (TRBs) can cross page boundaries, but they cannot cross 64KB boundaries. The buffer must be broken into multiple TRBs if a 64KB boundary is crossed. The sum of buffer lengths in all the TRBs in a Transfer Descriptor (TD) cannot exceed 64MB. To work around this, the enqueueing code must enqueue multiple TDs. The transfer event handler may incorrectly give back the URB in this case, if it gets a transfer event that points somewhere in the first TD. FIXME later. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Bandwidth allocation supportSarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the xHCI host controller hardware (xHC) has an internal schedule, it needs a better representation of what devices are consuming bandwidth on the bus. Each device is represented by a device context, with data about the device, endpoints, and pointers to each endpoint ring. We need to update the endpoint information for a device context before a new configuration or alternate interface setting is selected. We setup an input device context with modified endpoint information and newly allocated endpoint rings, and then submit a Configure Endpoint Command to the hardware. The host controller can reject the new configuration if it exceeds the bus bandwidth, or the host controller doesn't have enough internal resources for the configuration. If the command fails, we still have the older device context with the previous configuration. If the command succeeds, we free the old endpoint rings. The root hub isn't a real device, so always say yes to any bandwidth changes for it. The USB core will enable, disable, and then enable endpoint 0 several times during the initialization sequence. The device will always have an endpoint ring for endpoint 0 and bandwidth allocated for that, unless the device is disconnected or gets a SetAddress 0 request. So we don't pay attention for when xhci_check_bandwidth() is called for a re-add of endpoint 0. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Support for bandwidth allocation.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, the USB core had no support for allocating bandwidth when a particular configuration or alternate setting for an interface was selected. Instead, the device driver's URB submission would fail if there was not enough bandwidth for a periodic endpoint. Drivers could work around this, by using the scatter-gather list API to guarantee bandwidth. This patch adds host controller API to allow the USB core to allocate or deallocate bandwidth for an endpoint. Endpoints are added to or dropped from a copy of the current schedule by calling add_endpoint() or drop_endpoint(), and then the schedule is atomically evaluated with a call to check_bandwidth(). This allows all the endpoints for a new configuration or alternate setting to be added at the same time that the endpoints from the old configuration or alt setting are dropped. Endpoints must be added to the schedule before any URBs are submitted to them. The HCD must be allowed to reject a new configuration or alt setting before the control transfer is sent to the device requesting the change. It may reject the change because there is not enough bandwidth, not enough internal resources (such as memory on an embedded host controller), or perhaps even for security reasons in a virtualized environment. If the call to check_bandwidth() fails, the USB core must call reset_bandwidth(). This causes the schedule to be reverted back to the state it was in just after the last successful check_bandwidth() call. If the call succeeds, the host controller driver (and hardware) will have changed its internal state to match the new configuration or alternate setting. The USB core can then issue a control transfer to the device to change the configuration or alt setting. This allows the core to test new configurations or alternate settings before unbinding drivers bound to interfaces in the old configuration. WIP: The USB core must add endpoints from all interfaces in a configuration to the schedule, because a driver may claim that interface at any time. A slight optimization might be to add the endpoints to the schedule once a driver claims that interface. FIXME This patch does not cover changing alternate settings, but it does handle a configuration change or de-configuration. FIXME The code for managing the schedule is currently HCD specific. A generic scheduling algorithm could be added for host controllers without built-in scheduling support. For now, if a host controller does not define the check_bandwidth() function, the call to usb_hcd_check_bandwidth() will always succeed. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Parse and store the SuperSpeed endpoint companion descriptors.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB 3.0 bus specification added an "Endpoint Companion" descriptor that is supposed to follow all SuperSpeed Endpoint descriptors. This descriptor is used to extend the bus protocol to allow more packets to be sent to an endpoint per "microframe". The word microframe was removed from the USB 3.0 specification because the host controller does not send Start Of Frame (SOF) symbols down the USB 3.0 wires. The descriptor defines a bMaxBurst field, which indicates the number of packets of wMaxPacketSize that a SuperSpeed device can send or recieve in a service interval. All non-control endpoints may set this value as high as 16 packets (bMaxBurst = 15). The descriptor also allows isochronous endpoints to further specify that they can send and receive multiple bursts per service interval. The bmAttributes allows them to specify a "Mult" of up to 3 (bmAttributes = 2). Bulk endpoints use bmAttributes to report the number of "Streams" they support. This was an extension of the endpoint pipe concept to allow multiple mass storage device commands to be outstanding for one bulk endpoint at a time. This should allow USB 3.0 mass storage devices to support SCSI command queueing. Bulk endpoints can say they support up to 2^16 (65,536) streams. The information in the endpoint companion descriptor must be stored with the other device, config, interface, and endpoint descriptors because the host controller needs to access them quickly, and we need to install some default values if a SuperSpeed device doesn't provide an endpoint companion descriptor. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Control transfer support.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow device drivers to enqueue URBs to control endpoints on devices under an xHCI host controller. Each control transfer is represented by a series of Transfer Descriptors (TDs) written to an endpoint ring. There is one TD for the Setup phase, (optionally) one TD for the Data phase, and one TD for the Status phase. Enqueue these TDs onto the endpoint ring that represents the control endpoint. The host controller hardware will return an event on the event ring that points to the (DMA) address of one of the TDs on the endpoint ring. If the transfer was successful, the transfer event TRB will have a completion code of success, and it will point to the Status phase TD. Anything else is considered an error. This should work for control endpoints besides the default endpoint, but that hasn't been tested. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Allocate and address USB devicesSarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Support for addressing a USB device under xHCISarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Root hub support.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Add route string to struct usb_device.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a hex route string to each USB device. The route string is used by the USB 3.0 host controller to send packets through the device tree. USB 3.0 hubs use this string to route packets to the correct port. This is fundamental bus change from USB 2.0, where all packets were broadcast across the bus. Devices (including hubs) under a root port receive the route string 0x0. Every four bits in the route string represent a port on a hub. This length works because USB 3.0 hubs are limited to 15 ports, and USB 2.0 hubs (with potentially more ports) will never see packets with a route string. A port number of 0 means the packet is destined for that hub. For example, a peripheral device might have a route string of 0x00097. This means the device is connected to port 9 of the hub at depth 1. The hub at depth 1 is connected to port 7 of a hub at depth 0. The hub at depth 0 is connected to a root port. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Don't reset USB 3.0 devices on port change detection.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB 3.0 bus specification defines a new connection sequence for USB 3.0 hubs and roothubs. USB 3.0 devices are reset and link trained by the hub before the port status change notification is sent to the host OS. This means that an entire tree of devices can be trained in parallel on power up, and the OS no longer needs to reset USB 3.0 devices. Change the USB core's hub port init sequence so that it does not reset USB 3.0 devices. The port status change from the roothub and from the USB 3.0 hub will report the SuperSpeed connect correctly. This patch currently only handles the roothub case. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Add USB 3.0 roothub support to USB core.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add USB 3.0 root hub descriptors. This is a kludge because I reused the old USB 2.0 descriptors, instead of using the new USB 3.0 hub descriptors with endpoint companion descriptors and other descriptors. I did this because I wasn't ready to add USB 3.0 hub changes to khubd. For now, a USB 3.0 roothub looks like a USB 2.0 roothub, with a higher speed. USB 3.0 hubs have no transaction translator (TT). Make USB core debugging handle super speed ports. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Add SuperSpeed to the list of USB device speeds.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed". This is 5.0 Gbps (wire speed). There are probably more places that check for speed that I've missed. SuperSpeed devices have a 512 byte endpoint 0 max packet size. This shows up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus spec). xHCI spec says that the xHC can handle intervals up to 2^15 microframes. That might change when real silicon becomes available. Add FIXME note for SuperSpeed isochronous endpoints. They can transmit up to 16 packets in one "burst" before they wait for an acknowledgment of the packets. They can do up to 3 bursts per microframe (determined by the mult value in the endpoint companion descriptor). The xHCI driver doesn't have support for isoc yet, so fix this later. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: No-op command queueing and irq handler.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Device context array allocation.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of keeping a "frame list" like older host controllers, the xHCI host controller keeps internal representations of the USB devices, with a transfer ring per endpoint. The host controller queues Transfer Request Blocks (TRBs) to the endpoint ring, and then "rings the doorbell" for that device. The host controller processes the transfer, places a transfer completion event on the event ring, and interrupts the system. The device context base address array must be allocated by the xHCI host controller driver, along with the device contexts it points to. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Ring allocation and initialization.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 0 |--------------- ------------------------ Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: BIOS handoff and HW initialization.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add PCI initialization code to take control of the xHCI host controller away from the BIOS, halt, and reset the host controller. The xHCI spec says that BIOSes must give up the host controller within 5 seconds. Add some host controller glue functions to handle hardware initialization and memory allocation for the host controller. The current xHCI prototypes use PCI interrupts, but the xHCI spec requires MSI-X interrupts. Add code to support MSI-X interrupts, but use the PCI interrupts for now. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: xhci: Support xHCI host controllers and USB 3.0 devices.Sarah Sharp2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: usbtmc: fix switch statmentGreg Kroah-Hartman2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Steve Holland pointed out that we forgot to call break; in the switch statment. This probably resolves a lot of the bug reports I've gotten for the driver lately. Stupid me... Reported-by: Steve Holland <sdh4@iastate.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: usbtest fix endless loop in unlink tests.Martin Fuzzey2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In tests 11 and 12 if the URB completes with an error status (eg babble) the asynchrous unlink entered an endless loop trying to unlink a non resubmitted URB. Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com> Acked-by: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: atmel_usba_udc: change way of specifying bias functionNicolas Ferre2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The toggle_bias() function was specified differently for avr32 and at91 architectures. Now, new at91 have the same behavior as avr32. Consequently, we change to a particular chip function definition: only for at91sam9rl. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Avoid PM error messages during resume if a device was disconnectedFrans Pop2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently if a laptop is suspended e.g. while docked and then resumed after undocking it, the following errors get generated because the USB hub in the docking station and the devices connected to it are no longer available: pm_op(): usb_dev_resume+0x0/0x10 returns -19 PM: Device 1-2 failed to resume: error -19 pm_op(): usb_dev_resume+0x0/0x10 returns -19 PM: Device 1-2.2 failed to resume: error -19 pm_op(): usb_dev_resume+0x0/0x10 returns -19 PM: Device 1-2.3 failed to resume: error -19 As the removal of USB devices while a system is suspended is a relatively common use case and in most cases not an error, just return success on -ENODEV. The user gets informed anyway as the USB subsystem generates regular disconnect messages for the devices shortly afterwards: usb 1-2: USB disconnect, address 3 usb 1-2.2: USB disconnect, address 4 usblp0: removed usb 1-2.3: USB disconnect, address 5 Signed-off-by: Frans Pop <elendil@planet.nl> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Add Intel Langwell USB OTG Transceiver DriveHao Wu2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Description: This driver is used for Intel Langwell* USB OTG controller in Intel Moorestown* platform. It tries to implement host/device role switch according to OTG spec. The actual hsot and device functions are accomplished in modified EHCI driver and Intel Langwell USB OTG client controller driver. * Langwell and Moorestown are names used in development. They are not approved official name. Note: This patch is the first version Intel Langwell USB OTG Transceiver driver. The development is not finished, and the bug fixing is on going for some hardware and software issues. The main purpose of this submission is for code view. Supported features: - Data-line Pulsing SRP - Support HNP to switch roles - PCI D0/D3 power management support Known issues: - HNP is only tested with another Moorestown platform. - PCI D0/D3 power management support is not fully tested. - VBus Pulsing SRP is not support in current version. Signed-off-by: Hao Wu <hao.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: Add Intel Langwell USB Device Controller driverXiaochen Shen2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel Langwell USB Device Controller is a High-Speed USB OTG device controller in Intel Moorestown platform. It can work in OTG device mode with Intel Langwell USB OTG transceiver driver as well as device-only mode. The number of programmable endpoints is different through controller revision. NOTE: This patch is the first version Intel Langwell USB OTG device controller driver. The bug fixing is on going for some hardware and software issues. Intel Langwell USB OTG transceiver driver and EHCI driver patches will be submitted later. Supported features: - USB OTG protocol support with Intel Langwell USB OTG transceiver driver (turn on CONFIG_USB_LANGWELL_OTG) - Support control, bulk, interrupt and isochronous endpoints (isochronous not tested) - PCI D0/D3 power management support - Link Power Management (LPM) support Tested gadget drivers: - g_file_storage - g_ether - g_zero The passed tests: - g_file_storage: USBCV Chapter 9 tests - g_file_storage: USBCV MSC tests - g_file_storage: from/to host files copying - g_ether: ping, ftp and scp files from/to host - Hotplug, with and without hubs Known issues: - g_ether: failed part of USBCV chap9 tests - LPM support not fully tested TODO: - g_ether: pass all USBCV chap9 tests - g_zero: pass usbtest tests - Stress tests on different gadget drivers - On-chip private SRAM caching support Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| | * USB: usb-serial: replace shutdown with disconnect, releaseAlan Stern2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch (as1254) splits up the shutdown method of usb_serial_driver into a disconnect and a release method. The problem is that the usb-serial core was calling shutdown during disconnect handling, but drivers didn't expect it to be called until after all the open file references had been closed. The result was an oops when the close method tried to use memory that had been deallocated by shutdown. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>