There were some places that compared port_speed == -1 where port_speed
is a u8.  This doesn't work unless we cast the -1 to u8.  Some places
did it correctly.

Instead of using -1 directly, I've created a DUPLICATE_ENTRY define
which does the cast and is more descriptive as well.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Macro arguments used in expressions need to be enclosed in parenthesis
to avoid unpleasant surprises.

This should be queued for kernels back to 2.6.31
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer.  To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.

Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes.  However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.

Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command.  Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.

While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed.  This just won't work with
the internal xHCI state code.  I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB.  There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works.  Keep the fix simple until when/if we run into
that case.

This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org

When the xHCI host controller is halted, it won't respond to commands
placed on the command ring.  So if an URB is cancelled after the first
roothub is deallocated, it will try to place a stop endpoint command on
the command ring, which will fail.  The command watchdog timer will fire
after five seconds, and the host controller will be marked as dying, and
all URBs will be completed.

Add a flag to the xHCI's internal state variable for when the host
controller is halted.  Immediately return the canceled URB if the host
controller is halted.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch changes the xHCI driver to allocate two roothubs.  This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers.  This is a rather large patch, but it
can't be broken up, or it would break git-bisect.

Make the xHCI driver register its own PCI probe function.  This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub.  This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.

Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub.  This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.

The reset method will also mark the xHCI USB2 roothub as having an
integrated TT.  Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT.  We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.

Other details:
-------------

The roothub emulation code is changed to return the correct number of
ports for the two roothubs.  For the USB 3.0 roothub, it only reports the
USB 3.0 ports.  For the USB 2.0 roothub, it reports all the LS/FS/HS
ports.  The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.

The code for initializing a new device context must be changed to set the
proper roothub port number.  Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub.  Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.

The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.

The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.

There's also changes to the driver initialization and shutdown paths:

 1. Make sure that the xhci_hcd pointer is shared across the two
    usb_hcd structures.  The xhci_hcd pointer is allocated and the
    registers are mapped in when xhci_pci_setup() is called with the
    primary HCD.  When xhci_pci_setup() is called with the non-primary
    HCD, the xhci_hcd pointer is stored.

 2. Make sure to set the sg_tablesize for both usb_hcd structures.  Set
    the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
    DMA.  (The PCI DMA mask is set from the primary HCD further down in
    the xhci_pci_setup() function.)

 3. Ensure that the host controller doesn't start kicking khubd in
    response to port status changes before both usb_hcd structures are
    registered.  xhci_run() only starts the xHC running once it has been
    called with the non-primary roothub.  Similarly, the xhci_stop()
    function only halts the host controller when it is called with the
    non-primary HCD.  Then on the second call, it resets and cleans up the
    MSI-X irqs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

xhci_find_slot_id_by_port() tries to map the port index to the slot ID for
the USB device.  In the future, there will be two xHCI roothubs, and their
port indices will overlap.  Therefore, xhci_find_slot_id_by_port() will
need to use information in the roothub's usb_hcd structure to map the port
index and roothub speed to the right slot ID.

Add a new parameter to xhci_find_slot_id_by_port(), in order to pass in
the roothub's usb_hcd structure.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

There are several variables in the xhci_hcd structure that are related to
bus suspend and resume state.  There are a couple different port status
arrays that are accessed by port index.  Move those variables into a
separate structure, xhci_bus_state.  Stash that structure in xhci_hcd.

When we have two roothhubs that can be suspended and resumed separately,
we can have two xhci_bus_states, and index into the port arrays in each
structure with the fake roothub port index (not the real hardware port
index).
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Instead of allocating space for the whole xhci_hcd structure at the end of
usb_hcd, make the USB core allocate enough space for a pointer to the
xhci_hcd structure.  This will make it easy to share the xhci_hcd
structure across the two roothubs (the USB 3.0 usb_hcd and the USB 2.0
usb_hcd).

Deallocate the xhci_hcd at PCI remove time, so the hcd_priv will be
deallocated after the usb_hcd is deallocated.  We do this by registering a
different PCI remove function that calls the usb_hcd_pci_remove()
function, and then frees the xhci_hcd.  usb_hcd_pci_remove() calls
kput() on the usb_hcd structure, which will deallocate the memory that
contains the hcd_priv pointer, but not the memory it points to.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The USB core only allows up to 31 (USB_MAXCHILDREN) ports under a roothub.
The xHCI driver keeps track of which ports are suspended, which ports have
a suspend change bit set, and what time the port will be done resuming.
It keeps track of the first two by setting a bit in a u32 variable,
suspended_ports or port_c_suspend.  The xHCI driver currently assumes we
can have up to 256 ports under a roothub, so it allocates an array of 8
u32 variables for both suspended_ports and port_c_suspend.  It also
allocates a 256-element array to keep track of when the ports will be done
resuming.

Since we can only have 31 roothub ports, we only need to use one u32 for
each of the suspend state and change variables.  We simplify the bit math
that's trying to index into those arrays and set the correct bit, if we
assume wIndex never exceeds 30.  (wIndex is zero-based after it's
decremented from the value passed in from the USB core.)  Finally, we
change the resume_done array to only hold 31 elements.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>

The test of placing a number of command no-ops on the command ring and
counting the number of no-op events that were generated was only used
during the initial xHCI driver bring up.  This test is no longer used, so
delete it.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

xhci->ir_set points to __iomem region, but xhci_print_ir_set accepts
plain struct xhci_intr_reg * causing multiple sparse warning at call
sites and inside the fucntion when we try to read that memory.

Instead of adding __iomem qualifier to the argument let's rework the
function so it itself gets needed register set from xhci and prints
it.
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The unused space in the doorbell is now marked as RsvdZ, not RsvdP, so
we can avoid reading the doorbell before writing it.

Update the doorbell-related defines to produce the entire doorbell value
from a single macro.  Document the doorbell format in a comment.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
occur in any order in the PORTSC registers.  We cannot read the port speed
bits in the PORTSC registers at init time to determine the port speed,
since those bits are only valid when a USB device is plugged into the
port.

Instead, we read the "Supported Protocol Capability" registers in the xHC
Extended Capabilities space.  Those describe the protocol, port offset in
the PORTSC registers, and port count.  We use those registers to create
two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
another for USB 2.0 ports.  A third array keeps track of the port protocol
major revision, and is indexed with the internal xHCI port number.

This commit is a bit big, but it should be queued for stable because the "Don't
let the USB core disable SuperSpeed ports" patch depends on it.  There is no
other way to determine which ports are SuperSpeed ports without this patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NDon Zickus <dzickus@redhat.com>
Cc: stable@kernel.org

USB2.0 spec 9.6.6 says: For all endpoints, bit 10..0 specify the maximum
packet size(in bytes).

So the wMaxPacketSize mask should be 0x7ff rather than 0x3ff.

This patch should be queued for the stable tree.  The bug in
xhci_endpoint_init() was present as far back as 2.6.31, and the bug in
xhci_get_max_esit_payload() was present when the function was introduced
in 2.6.34.
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Fix these linker errors when CONFIG_PM=n:

ERROR: "xhci_bus_resume" [drivers/usb/host/xhci-hcd.ko] undefined!
ERROR: "xhci_bus_suspend" [drivers/usb/host/xhci-hcd.ko] undefined!
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch implements the PCI suspend/resume.

Please refer to xHCI spec for doing the suspend/resume operation.

For S3, CSS/SRS in USBCMD is used to save/restore the internal state.
However, an error maybe occurs while restoring the internal state.
In this case, it means that HC internal state is wrong and HC will be
re-initialized.
Signed-off-by: NLibin Yang <libin.yang@amd.com>
Signed-off-by: NDong Nguyen <dong.nguyen@amd.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch implements xHCI bus suspend/resume function hook.

In the patch it goes through all the ports and suspend/resume
the ports if needed.

If any port is in remote wakeup, abort bus suspend as what ehci/ohci do.
Signed-off-by: NLibin Yang <libin.yang@amd.com>
Signed-off-by: NCrane Cai <crane.cai@amd.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This commit implements port remote wakeup.

When a port is in U3 state and resume signaling is detected from a device,
the port transitions to the Resume state, and the xHC generates a Port Status
Change Event.

For USB3 port, software write a '0' to the PLS field to complete the resume
signaling. For USB2 port, the resume should be signaling for at least 20ms,
irq handler set a timer for port remote wakeup, and then finishes process in
hub_control GetPortStatus.

Some codes are borrowed from EHCI code.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add software trigger USB device suspend resume function hook.
Do port suspend & resume in terms of xHCI spec.

Port Suspend:
Stop all endpoints via Stop Endpoint Command with Suspend (SP) flag set.
Place individual ports into suspend mode by writing '3' for Port Link State
(PLS) field into PORTSC register. This can only be done when the port is in
Enabled state. When writing, the Port Link State Write Strobe (LWS) bit shall
be set to '1'.
Allocate an xhci_command and stash it in xhci_virt_device to wait completion for
the last Stop Endpoint Command.  Use the Suspend bit in TRB to indicate the Stop
Endpoint Command is for port suspend. Based on Sarah's suggestion.

Port Resume:
Write '0' in PLS field, device will transition to running state.
Ring an endpoints' doorbell to restart it.

Ref: USB device remote wake need another patch to implement. For details of
how USB subsystem do power management, please see:
    Documentation/usb/power-management.txt
Signed-off-by: NCrane Cai <crane.cai@amd.com>
Signed-off-by: NLibin Yang <libin.yang@amd.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xHCI driver uses hardware assigned device address. This may cause device
address conflict in certain cases.

Use kernel assigned address for devices under xHCI. Store the xHC assigned
address locally in xHCI driver.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Rename xhci_reset_device() to xhci_discover_or_reset_device().
If xhci_discover_or_reset_device() is called to reset a device which does
not exist or does not match the udev, it calls xhci_alloc_dev() to
re-allocate the device.

This would prevent the reset device failure, possibly due to the xHC restore
error during S3/S4 resume.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add a pointer to udev in struct xhci_virt_device. When allocate a new
virt_device, make the pointer point to the corresponding udev.

Modify xhci_check_args(), check if virt_dev->udev matches the target udev,
to make sure command is issued to the right device.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that the event handler functions no longer use xhci_set_hc_event_deq()
to update the event ring dequeue pointer, that function is not used by
anything in xhci-ring.c.  Move that function into xhci-mem.c and make it
static.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xhci_handle_event() is now only called from within xhci-ring.c, so make it
static.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Most of the work for interrupt handling is done in xhci-ring.c, so it makes
sense to move the functions that are first called when an interrupt happens
(xhci_irq() or xhci_msi_irq()) into xhci-ring.c, so that the compiler can better
optimize them.

Shorten some lines to make it pass checkpatch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I've been using perf to measure the top symbols while transferring 1GB of data
on a USB 3.0 drive with dd.  This is using the raw disk with /dev/sdb, with a
block size of 1K.

During performance testing, the top symbol was xhci_triad_to_transfer_ring(), a
function that should return immediately if streams are not enabled for an
endpoint.  It turned out that the functions to find the endpoint ring was
defined in xhci-mem.c and used in xhci-ring.c and xhci-hcd.c.  I moved a copy of
xhci_triad_to_transfer_ring() and xhci_urb_to_transfer_ring() into xhci-ring.c
and declared them static.  I also made a static version of
xhci_urb_to_transfer_ring() in xhci.c.

This improved throughput on a 1GB read of the raw disk with dd from
186MB/s to 195MB/s, and perf reported sampling the xhci_triad_to_transfer_ring()
0.06% of the time, rather than 9.26% of the time.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch implements isochronous urb enqueue and interrupt handler part.

When an isochronous urb is passed to xHCI driver, first check the transfer
ring to guarantee there is enough room for the whole urb. Then update the
start_frame and interval field of the urb. Always assume URB_ISO_ASAP
is set, and never use urb->start_frame as input.

The number of isoc TDs is equal to urb->number_of_packets. One isoc TD is
consumed every Interval. Each isoc TD consists of an Isoch TRB chained to
zero or more Normal TRBs.

Call prepare_transfer for each TD to do initialization; then calculate the
number of TRBs needed for each TD. If the data required by an isoc TD is
physically contiguous (not crosses a page boundary), then only one isoc TRB
is needed; otherwise one or more additional normal TRB shall be chained to
the isoc TRB by the host.

Set TRB_IOC to the last TRB of each isoc TD. Do not ring endpoint doorbell
to start xHC procession until all the TDs are inserted to the endpoint
transer ring.

In irq handler, update urb status and actual_length, increase
urb_priv->td_cnt. When all the TDs are completed(td_cnt is equal to
urb_priv->length), giveback the urb to usbcore.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add urb_priv data structure to xHCI driver. This structure allows multiple
xhci TDs to be linked to one urb, which is essential for isochronous
transfer. For non-isochronous urb, only one TD is needed for one urb;
for isochronous urb, the TD number for the urb is equal to
urb->number_of_packets.

The length field of urb_priv indicates the number of TDs in the urb.
The td_cnt field indicates the number of TDs already processed by xHC.
When td_cnt matches length, the urb can be given back to usbcore.

When an urb is dequeued or cancelled, add all the unprocessed TDs to the
endpoint's cancelled_td_list. When process a cancelled TD, increase
td_cnt field. When td_cnt equals urb_priv->length, giveback the
cancelled urb.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds mechanism to process Missed Service Error Event.
Sometimes the xHC is unable to process the isoc TDs in time, it will
generate Missed Service Error Event. In this case some TDs on the ring are
not processed and missed. When encounter a Missed Servce Error Event, set
the skip flag of the ep, and process the missed TDs until reach the next
processed TD, then clear the skip flag.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Enable MSI/MSI-X supporting in xhci driver.

Provide the mechanism to fall back using MSI and Legacy IRQs
if MSI-X IRQs register failed.
Signed-off-by: NDong Nguyen <Dong.Nguyen@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a configured device is reset, the control endpoint's ring is reused.
If control transfers to the device were issued before the device is reset,
the dequeue pointer will be somewhere in the middle of the ring.  If the
device is then issued an address with the set address command, the xHCI
driver must provide a valid input context for control endpoint zero.

The original code would give the hardware the original input context,
which had a dequeue pointer set to the top of the ring.  This would cause
the host to re-execute any control transfers until it reached the ring's
enqueue pointer.  When issuing a set address command for a device that has
just been configured and then reset, use the control endpoint's enqueue
pointer as the hardware's dequeue pointer.

Assumption:  All control transfers will be completed or cancelled before
the set address command is issued to the device.  If there are any
outstanding control transfers, this code will not work.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The NEC xHCI host controller firmware version can be found by putting a
vendor-specific command on the command ring and extracting the BCD
encoded-version out of the vendor-specific event TRB.

The firmware version debug line in dmesg will look like:

xhci_hcd 0000:05:00.0: NEC firmware version 30.21

(NEC merged with Renesas Technologies and became Renesas Electronics on
April 1, 2010.  I have their OK to merge this vendor-specific code.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Satoshi Otani <satoshi.otani.xm@renesas.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>

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>

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>

Randy Dunlap reported this error when compiling the xHCI driver:

linux-next-20100104/drivers/usb/host/xhci.h:1214:
sorry, unimplemented: inlining failed in call to 'xhci_get_slot_state': function body not available

The xhci_get_slot_state() function belongs in xhci-dbg.c, since it
involves debugging internal xHCI structures.  However, it is only used in
xhci-hcd.c.  Some toolchains may have issues since the inlined function
body is not in the xhci.h header file.  Remove the inline keyword to avoid
this.
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add a new host controller driver method, reset_device(), that the USB core
will use to notify the host of a successful device reset.  The call may
fail due to out-of-memory errors; attempt the port reset sequence again if
that happens.  Update hub_port_init() to allow resetting a configured
device.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a USB device is reset, the xHCI hardware must know, in order to match
the device state and disable all endpoints except control endpoint 0.
Issue a Reset Device command after a USB device is successfully reset.
Wait on the command to finish, and then cache or free the disabled
endpoint rings.

There are four different USB device states that the xHCI hardware tracks:
 - disabled/enabled - device connection has just been detected,
 - default - the device has been reset and has an address of 0,
 - addressed - the device has a non-zero address but no configuration has
   been set,
 - configured - a set configuration succeeded.

The USB core may issue a port reset when a device is in any state, but the
Reset Device command will fail for a 0.96 xHC if the device is not in the
addressed or configured state.  Don't consider this failure as an error,
but don't free any endpoint rings if this command fails.

A storage driver may request that the USB device be reset during error
handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory
for the Reset Device command.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>