This patch (as1380) fixes a bug in the wakeup settings for EHCI host
controllers.  When the controller is suspended, if it isn't enabled
for remote wakeup then we have to turn off all the port wakeup flags.
Disabling PCI PME# isn't good enough, because some systems (Intel)
evidently use alternate wakeup signalling paths.

In addition, the patch improves the handling of the Intel Moorestown
hardware by performing various power-up and power-down delays just
once instead of once for each port (i.e., the delays are moved outside
of the port loops).  This requires extra code, but the total delay
time is reduced.

There are also a few additional minor cleanups.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NOndrej Zary <linux@rainbow-software.org>
CC: Alek Du <alek.du@intel.com>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is a bug fix for PHCD (phy clock disable) low power feature:
After PHCD is set, any write to PORTSC register is illegal, so when
resume ports, clear PHCD bit first.
Signed-off-by: NAlek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Our virtual xHCI device can have as many ports as we like - I've tested
this patch with 31.
Signed-off-by: NWilliam Gulland <wgulland@vmware.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

An undocumented "feature" in the OMAP3 EHCI controller causes
suspended ports to be taken out of suspend when the USBCMD.Run/Stop
bit is cleared (this bit is normally cleared when ehci_bus_suspend
is called).

This "feature" breaks suspend-resume if the root-hub is allowed
to suspend. (The controller thinks it is in resume, and the PHY
thinks it is still in suspend).

There is an undocumented register bit that can be used to disable
this feature and restore normal behavior. Set this bit so
suspend-resume can work normally.

Tested on OMAP3 SDPs with the NXP ISP1504 and NXP ISP1703 PHYs.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Macro TRB_TYPE is misused in some places. Fix the wrong usage.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change transfer ring behavior to not follow/activate link TRBs
until active TRBs are queued after it.  This change affects
the behavior when a TD ends just before a link TRB.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On OMAP systems, we have two different OHCI controllers. The legacy
one is present in OMAP1/2 chips, and the newer one comes bundled as
a companion to the EHCI controller on OMAP3 and newer chips.

We may have multi-omap configurations where OMAP2 and OMAP3
support may be enabled in the same kernel, and need a mechanism
to keep both drivers around.

This patch adds a Kconfig entry for each of these drivers.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add support for the OHCI controller present in OMAP3 and newer chips.

The code is mostly based off the ehci-omap.c driver.
Some of it is common to both drivers and will eventually
need to be factored out to platform init files.

In its current state, the driver cannot co-exist with the ehci-omap
driver, and this will be fixed in later versions. The second driver
to be loaded will overwrite settings made by the other. For now,
this driver should allow the few users of OMAP3 OHCI to get going.
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There were some reports[1] of isp1760 USB driver malfunctioning
with high speed devices, noticed on Blackfin and PowerPC targets.
These reports indicated that the original Philips 'pehcd'[2]
driver worked fine.

We've noticed the same issue with an ARM RealView platform. This
happens under load (with only some mass storage devices, not all,
just as in another report[3]):

  error bit is set in DW3
  error bit is set in DW3
  error bit is set in DW3
  usb 1-1.2: device descriptor read/64, error -32

It appears that the 'pehcd' driver checks the X bit only if the
transaction is halted (H bit), otherwise the error is so far
insignificant.

The ISP176x chips were modeled after EHCI, and EHCI spec says
(thanks to Alan Stern for pointing out):

"Transaction errors cause the status field to be updated to reflect
 the type of error, but the transaction continues to be retried until
 the Active bit is set to 0.  When the error counter reaches 0, the
 Halt bit is set and the Active bit is cleared."

So, just as the original Philips driver, isp1760 must report the
error only if the transaction error and the halt bits are set.

[1] http://markmail.org/message/lx4qrlbrs2uhcnly
[2] svn co svn://sources.blackfin.uclinux.org/linux-kernel/trunk/drivers/usb/host -r 5494
    See pehci.c:pehci_hcd_update_error_status().
[3] http://blackfin.uclinux.org/gf/tracker/5148Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix gcc warning on mixed declarations/code:
drivers/usb/host/u132-hcd.c:1450: warning: ISO C90 forbids mixed declarations and code
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After using state stored in xhci_virt_ep to clean up a stalled endpoint,
be sure to set the stalled stream ID back to 0.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the resource_size function instead of manually calculating the
resource size.  This reduces the chance of introducing off-by-one
errors.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change the type of the URB's 'sg' pointer from a usb_sg_request to
a scatterlist.  This allows drivers to submit scatter-gather lists
without using the usb_sg_wait() interface.  It has the added benefit
of removing the typecasts that were added as part of patch as1368 (and
slightly decreasing the number of pointer dereferences).
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

qset_print() was not declared static although it is not used
outside of debug.c
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

AM3517 is based on ES3.1 thus ES2.x related programming is invalid
for it so updating ES2.x programming.

Also fixed below checkpatch warning:
WARNING: unnecessary whitespace before a quoted newline
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixes below compilation warning:
drivers/usb/host/ehci-hcd.c:425:
	warning: 'ehci_port_power' defined but not used
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a device is disconnected, xhci_free_virt_device() is called.  Ramya
found that if the device had streams enabled, and then the driver freed
the streams with a call to usb_free_streams(), then about a minute after
he had called this, his machine crashed with a Bad DMA error.  It turns
out that xhci_free_virt_device() would attempt to free the endpoint's
stream_info data structure if it wasn't NULL, and the free streams
function was not setting it to NULL after freeing it.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NRamya Desai <ramya.desai@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1375) eliminates the usb_host_ss_ep_comp structure used
for storing a dynamically-allocated copy of the SuperSpeed endpoint
companion descriptor.  The SuperSpeed descriptor is placed directly in
the usb_host_endpoint structure, alongside the standard endpoint
descriptor.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix usb sparse warnings:

drivers/usb/host/isp1362-hcd.c:2220:50: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:43:24: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:49:24: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:161:24: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:198:16: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:319:31: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:1231:33: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-pci.c:177:23: warning: non-ANSI function declaration of function 'xhci_register_pci'
drivers/usb/host/xhci-pci.c:182:26: warning: non-ANSI function declaration of function 'xhci_unregister_pci'
drivers/usb/host/xhci-ring.c:342:32: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-ring.c:525:34: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-ring.c:1009:32: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-ring.c:1031:32: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-ring.c:1041:16: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-ring.c:1096:30: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-ring.c:1100:27: warning: Using plain integer as NULL pointer
drivers/usb/host/xhci-mem.c:224:27: warning: symbol 'xhci_alloc_container_ctx' was not declared. Should it be static?
drivers/usb/host/xhci-mem.c:242:6: warning: symbol 'xhci_free_container_ctx' was not declared. Should it be static?
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Signed-off By: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I've been running with this patch on my Niagara2 boxes for some time
and have not seen any ill effects yet.  Maybe we can stash this into
the USB tree to get exposure for some time in -next and if anything
crops up we can simply revert?
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Bulk endpoint streams were added in the USB 3.0 specification.  Streams
allow a device driver to overload a bulk endpoint so that multiple
transfers can be queued at once.

The device then decides which transfer it wants to work on first, and can
queue part of a transfer before it switches to a new stream.  All this
switching is invisible to the device driver, which just gets a completion
for the URB.  Drivers that use streams must be able to handle URBs
completing in a different order than they were submitted to the endpoint.

This requires adding new API to set up xHCI data structures to support
multiple queues ("stream rings") per endpoint.  Drivers will allocate a
number of stream IDs before enqueueing URBs to the bulk endpoints of the
device, and free the stream IDs in their disconnect function.  See
Documentation/usb/bulk-streams.txt for details.

The new mass storage device class, USB Attached SCSI Protocol (UASP), uses
these streams API.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Much of the xHCI driver code assumes that endpoints only have one ring.
Now an endpoint can have one ring per enabled stream ID, so correct that
assumption.  Use functions that translate the stream_id field in the URB
or the DMA address of a TRB into the correct stream ring.

Correct the polling loop to print out all enabled stream rings.  Make the
URB cancellation routine find the correct stream ring if the URB has
stream_id set.  Make sure the URB enqueueing routine does the same.  Also
correct the code that handles stalled/halted endpoints.

Check that commands and registers that can take stream IDs handle them
properly.  That includes ringing an endpoint doorbell, resetting a
stalled/halted endpoint, and setting a transfer ring dequeue pointer
(since that command can set the dequeue pointer in a stream context or an
endpoint context).

Correct the transfer event handler to translate a TRB DMA address into the
stream ring it was enqueued to.  Make the code to allocate and prepare TD
structures adds the TD to the right td_list for the stream ring.  Make
sure the code to give the first TRB in a TD to the hardware manipulates
the correct stream ring.

When an endpoint stalls, store the stream ID of the stream ring that
stalled in the xhci_virt_ep structure.  Use that instead of the stream ID
in the URB, since an URB may be re-used after it is given back after a
non-control endpoint stall.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add support for allocating streams for USB 3.0 bulk endpoints.  See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.

When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings.  The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array".  This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.

The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries).  These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.

Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure.  The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event.  For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.

Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place.  Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.

We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls.  (It is
not advised, however, since it is a waste of resources and time.)

Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command.  It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command.  We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth.  The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).

If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers.  It's an unavoidable consequence
of broken host controller hardware.

Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1368) fixes a rather obscure bug in usbmon: When tracing
URBs sent by the scatter-gather library, it accesses the data buffers
while they are still mapped for DMA.

The solution is to move the mapping and unmapping out of the s-g
library and into the usual place in hcd.c.  This requires the addition
of new URB flag bits to describe the kind of mapping needed, since we
have to call dma_map_sg() if the HCD supports native scatter-gather
operation and dma_map_page() if it doesn't.  The nice thing about
having the new flags is that they simplify the testing for unmapping.

The patch removes the only caller of usb_buffer_[un]map_sg(), so those
functions are #if'ed out.  A later patch will remove them entirely.

As a result of this change, urb->sg will be set in situations where
it wasn't set previously.  Hence the xhci and whci drivers are
adjusted to test urb->num_sgs instead, which retains its original
meaning and is nonzero only when the HCD has to handle a scatterlist.

Finally, even when a submission error occurs we don't want to hand
URBs to usbmon before they are unmapped.  The submission path is
rearranged so that map_urb_for_dma() is called only for non-root-hub
URBs and unmap_urb_for_dma() is called immediately after a submission
error.  This simplifies the error handling.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I've been running variations of this patch for well over a year now;
my usual zoo of test devices didn't trigger any ill effects even
under heavy load.  As a nice sideeffect idle-wakeups are reduced
from 20/s to about 2/s (EHCI hub with mouse and kbd).
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1349b) clears up the confusion in many USB host
controller drivers between port features and port statuses.  In mosty
cases it's true that the status bit is in the position given by the
corresponding feature value, but that's not always true and it's not
guaranteed in the USB spec.

There's no functional change, just replacing expressions of the form
(1 << USB_PORT_FEAT_x) with USB_PORT_STAT_x, which has the same value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1348) removes the bogus
USB_PORT_FEAT_{HIGHSPEED,SUPERSPEED} symbols from ch11.h.  No such
features are defined by the USB spec.  (There is a PORT_LOWSPEED
feature, but the spec doesn't mention it except to say that host
software should never use it.)  The speed indicators are port
statuses, not port features.

As a temporary workaround for the xhci-hcd driver, a fictional
USB_PORT_STAT_SUPER_SPEED symbol is added.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The usbcore headers: hcd.h and hub.h are shared between usbcore,
HCDs and a couple of other drivers (e.g. USBIP modules).
So, it makes sense to move them into a more public location and
to cleanup dependency of those modules on kernel internal headers.
This patch moves hcd.h from drivers/usb/core into include/linux/usb/
Signed-of-by: NEric Lescouet <eric@lescouet.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The length of the scatter gather list a driver can enqueue is limited by
the bus' sg_tablesize to 62 entries.  Each entry will be described by at
least one transfer request block (TRB).  If the entry's buffer crosses a
64KB boundary, then that entry will have to be described by two or more
TRBs.  So even if the USB device driver respects sg_tablesize, the whole
scatter list may take more than 62 TRBs to describe, and won't fit on
the ring.

Don't assume that an empty ring means there is enough room on the
transfer ring.  The old code would unconditionally queue this too-large
transfer, and over write the beginning of the transfer.  This would mean
the cycle bit was unchanged in those overwritten transfers, causing the
hardware to think it didn't own the TRBs, and the host would seem to
hang.

Now drivers may see submit_urb() fail with -ENOMEM if the transfers are
too big to fit on the ring.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a scatter-gather list is enqueued to the xHCI driver, it translates
each entry into a transfer request block (TRB).  Only 63 TRBs can be
used per ring segment, and there must be one additional TRB reserved to
make sure the hardware does not think the ring is empty (so the enqueue
pointer doesn't equal the dequeue pointer).  Limit the bus sg_tablesize
to 62 TRBs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When the USB core installs a new interface, it unconditionally clears the
halts on all the endpoints on the new interface.  Usually the xHCI host
needs to know when an endpoint is reset, so it can change its internal
endpoint state.  In this case, it doesn't care, because the endpoints were
never halted in the first place.

To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks
at xhci_virt_ep->stopped_td to determine if the endpoint was actually
halted.  However, the functions that handle the stall never set that
variable to NULL after it dealt with the stall.  So if an endpoint stalled
and a Reset Endpoint command completed, and then the class driver tried to
install a new alternate setting, the xHCI driver would access the old
xhci_virt_ep->stopped_td pointer.  A similar problem occurs if the
endpoint has been stopped to cancel a transfer.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A while ago I provided a patch that fixed device detection after device
removal (USB: sl811-hcd: Fix device disconnect).
Chris Brissette pointed out that the detection/removal counter method
to distinguish insert or remove my fail under certain conditions.
Latest SL811HS datasheet (Document 38-08008 Rev. *D) indicates that
bit 6 (SL11H_INTMASK_RD) of the Interrupt Status Register together with
bit 5 (SL11H_INTMASK_INSRMV) can be used to determine whether a device
has been inserted or removed.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A hanging has been detected in ohci-at91 while going in suspend to ram. This is
due to asynchronous operations between ohci reset and ohci clocks shutdown.
This patch adds the reading of the control register between the reset of the
ohci and clocks stop. This "flush the writes" idea was taken from ohci-hcd.c
file (ohci_shutdown() function).
Signed-off-by: NPatrice Vilchez <patrice.vilchez@atmel.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Smatch complained about this missing spinlock.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval.  The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload).  This is used by the hardware for bandwidth
management and scheduling of packets.

For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor).  Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.

For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).

For FS/LS devices, this is just the max packet size.

The other thing we must set in the endpoint context is the Average TRB
Length.  This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD.  This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.

It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together.  Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD.  The Linux
xHCI driver does not use Event Data TRBs.

In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately.  For now,
we set it to the same number as the Max ESIT payload.

The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A SuperSpeed interrupt or isochronous endpoint can define the number of
"burst transactions" it can handle in a service interval.  This is
indicated by the "Mult" bits in the bmAttributes of the SuperSpeed
Endpoint Companion Descriptor.  For example, if it has a max packet size
of 1024, a max burst of 11, and a mult of 3, the host may send 33
1024-byte packets in one service interval.

We must tell the xHCI host controller the number of multiple service
opportunities (mults) the device can handle when the endpoint is
installed.  We do that by setting the Mult field of the Endpoint Context
before a configure endpoint command is sent down.  The Mult field is
invalid for control or bulk SuperSpeed endpoints.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1371) fixes a small bug in ohci-hcd.  The HCD already
knows how many ports the controller has; there's no need to go looking
at the root hub's usb_device structure to find out.  Especially since
the root hub's maxchild value is set correctly only while the root hub
is bound to the hub driver.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

It seems that for USB IP on Freescale MX5x processors, it needs >750
usec for the reset to complete. This change should not hurt any other
EHCI hardware.
Signed-off-by: NDinh Nguyen <Dinh.Nguyen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1369) fixes a problem in ehci-hcd.  Some controllers
occasionally run into trouble when the driver reclaims siTDs too
quickly.  This can happen while streaming audio; it causes the
controller to crash.

The patch changes siTD reclamation to work the same way as iTD
reclamation: Completed siTDs are stored on a list and not reused until
at least one frame has passed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NNate Case <ncase@xes-inc.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>