This reverts commit df711fc9.

The commit added a reset-on-resume quirk because the NEC chipset stopped
responding to commands about 30 minutes after a system resume from
suspend.  We thought it was a chipset issue, but it turns out that the
xHCI driver was zeroing out the link TRB after a successful context
restore during resume.  The host controller would fall off the command
ring sometime later, causing it to not respond to new commands.

The link TRB issue has been fixed with commit
158886cd "xHCI: fix bug in
xhci_clear_command_ring()", so revert the reset-on-resume quirk, as it's
not necessary.

Commit df711fc9 was marked for stable
trees back to 2.6.37, but according to my mail, it has not made it into
Linus' tree or the stable trees yet.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NJulian Sikorski <belegdol@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>

Julian Sikorski reports NEC uPD720200 does not work stable after suspend
and resume. Re-initialize the host in xhci_resume().

This should be backported to stable kernels as old as 2.6.37.  The
kernel will need to include
commit c877b3b2
"xhci: Add reset on resume quirk for asrock p67 host"
for this patch to work.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Reported-by: NJulian Sikorski <belegdol@gmail.com>
Tested-by: NJulian Sikorski <belegdol@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The situation up to this point meant that module.h was pretty
much everywhere, regardless of whether you asked for it or not.
We are fixing that, so give the USB folks who want it an actual
include of it.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

This removes the need of ifdefs within the init function and with it the
headache about the correct clean without bus X but with bus/platform Y &
Z.
xhci-pci is only compiled if CONFIG_PCI is selected which can be
de-selected now without trouble. For now the result is kinda useless
because we have no other glue code. However, since nobody is using
USB_ARCH_HAS_XHCI then it should not be an issue :)
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xhci_gen_setup() is generic so it can be used to perform the bare xhci
setup even on non-pci based platform. The typedef for the function
pointer is moved into the headerfile
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xhci_pci_setup() is split into three pieces:

- xhci_gen_setup()
  The major remaining of xhci_pci_setup() is now containing the generic
  part of the xhci setup. It allocates the xhci struct, setup
  hcs_params? and friends, performs xhci_halt(), xhci_init and so one.
  It also obtains the quirks via a callback
- xhci_pci_quirks()
  It checks the origin of the xhci core and sets core specific quirks.
- xhci_pci_setup()
  PCI specific setup functions. Besides calling xhci_gen_setup() with
  xhci_pci_quirks() as an argument it performs PCI specific setup like
  obtaining the address of sbrn via a PCI config space.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Setting the chain (CH) bit in the link TRB of isochronous transfer rings
is required by AMD 0.96 xHCI host controller to successfully transverse
multi-TRB TD that span through different memory segments.

When a Missed Service Error event occurs, if the chain bit is not set in
the link TRB and the host skips TDs which just across a link TRB, the
host may falsely recognize the link TRB as a normal TRB. You can see
this may cause big trouble - the host does not jump to the right address
which is pointed by the link TRB, but continue fetching the memory which
is after the link TRB address, which may not even belong to the host,
and the result cannot be predicted.

This causes some big problems. Without the former patch I sent: "xHCI:
prevent infinite loop when processing MSE event", the system may hang.
With that patch applied, system does not hang, but the host still access
wrong memory address and isoc transfer will fail. With this patch,
isochronous transfer works as expected.

This patch should be applied to kernels as old as 2.6.36, which was when
the first isochronous support was added for the xHCI host controller.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the device pass the USB2 software LPM and the host supports hardware
LPM, enable hardware LPM for the device to let the host decide when to
put the link into lower power state.

If hardware LPM is enabled for a port and driver wants to put it into
suspend, it must first disable hardware LPM, resume the port into U0,
and then suspend the port.
Signed-off-by: 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 tests USB2 software LPM for a USB2 LPM-capable device.

When a lpm-capable device is addressed, if the host also supports software
LPM, apply a test by putting the device into L1 state and resume it to see
if the device can do L1 suspend/resume successfully.

If the device fails to enter L1 or resume from L1 state, it may not
function normally and usbcore may disconnect and re-enumerate it. In this
case, store the device's Vid and Pid information, make sure the host will
not test LPM for it twice.

The test result is per device/host. Some devices claim to be lpm-capable,
but fail to enter L1 or resume. So the test is necessary.

The xHCI 1.0 errata has modified the USB2.0 LPM implementation. It redefines
the HIRD field to BESL, and adds another register Port Hardware LPM Control
(PORTHLPMC). However, this should not affect the LPM behavior on xHC which
does not implement 1.0 errata.

USB2.0 LPM errata defines a new bit BESL in the device's USB 2.0 extension
descriptor. If the device reports it uses BESL, driver should use BESL
instead of HIRD for it.
Signed-off-by: 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 flag is a NOOP and can be removed now.
Signed-off-by: NYong Zhang <yong.zhang0@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The xHCI host controller in the Intel Panther Point chipset needs to have
software check whether new devices will fit in the available bus
bandwidth.  Activate the software bandwidth checking quirk when we find
the right PCI device.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.

This should be backported to stable kernels as old as 2.6.37.
Signed-off-by: NMaarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
advertise MSI, but fail to actually generate MSI interrupts.  Add a new
xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
ID 0x1000, regardless of PCI revision ID, do not support MSI.

This should be backported to stable kernels as far back as 2.6.36, which
was the first kernel to support MSI on xHCI hosts.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NSergey Galanov <sergey.e.galanov@gmail.com>
Cc: stable@kernel.org

The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle.  Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't.  Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.

Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active.  This gets a little
tricky, because commands to change the number of active endpoints can
fail.  This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.

Fail a new device allocation if we don't have room for the new default
control endpoint.  Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.

Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints.  That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed.  If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.

To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints.  Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources.  When the configure
endpoint command completes, subtract off the dropped endpoints.

This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.

(Originally my plan had been to push the resource allocation down into the
ring allocation functions.  However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds.  A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring.  If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring.  Then it puts a Transfer Event with a successful completion
code on the ring for the same TD.  The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event.  These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.

This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports.  These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space.  The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.

This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support.  By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds.  (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.)  Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.

This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration.  We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.

Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI.  The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.

Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices.  It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.

Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions.  We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions.  Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.

The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet.  I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch.  I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Commit b02d0ed6 ('xhci: Change
hcd_priv into a pointer') added calls to kzalloc() and kfree() in
xhci-pci.c.  On most architectures <linux/slab.h> is indirectly
included, but on some it is not.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:

1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.

AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Make sure the HCD_FLAG_HW_ACCESSIBLE flag is mirrored by both roothubs,
since it refers to whether the shared hardware is accessible.  Make sure
each bus is marked as suspended by setting usb_hcd->state to
HC_STATE_SUSPENDED when the PCI host controller is resumed.
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>

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>

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>

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>

Tell the USB core that we can do DMA directly (instead of needing it to
memory-map the buffers for PIO).  If the xHCI host supports 64-bit addresses,
set the DMA mask accordingly.  Otherwise indicate the host can handle 32-bit DMA
addresses.

This improves performance because the USB core doesn't have to spend time
remapping buffers in high memory into the 32-bit address range.
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>

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>

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>

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>

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>

The WHCI HCD will also support urbs with scatter-gather lists.  Add a
usb_bus field to indicated how many sg list elements are supported by
the HCD.  Use this to decide whether to pass the scatter-list to the HCD
or not.

Make the usb-storage driver use this new field.
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add a hook for updating xHCI internal structures after khubd fetches the
hub descriptor and sets up the hub's TT information.  The xHCI driver must
update the internal structures before devices under the hub can be
enumerated.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

For a USB hub to work under an xHCI host controller, the xHC's internal
scheduler must be made aware of the hub's characteristics.  Add an xHCI
hook that the USB core will call after it fetches the hub descriptor.
This hook will add hub information to the slot context for that device,
including whether it has multiple TTs or a single TT, the number of ports
on the hub, and TT think time.

Setting up the slot context for the device is different for 0.95 and 0.96
xHCI host controllers.

Some of the slot context reserved fields in the 0.95 specification were
changed into hub fields in the 0.96 specification.  Don't set the TT think
time or number of ports for a hub if we're dealing with a 0.95-compliant
xHCI host controller.

The 0.95 xHCI specification says that to modify the hub flag, we need to
issue an evaluate context command.  The 0.96 specification says that flag
can be set with a configure endpoint command.  Issue the correct command
based on the version reported by the hardware.

This patch does not add support for multi-TT hubs.  Multi-TT hubs expose
a single TT on alt setting 0, and multi-TT on alt setting 1.  The xHCI
driver can't handle setting alternate interfaces yet.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This Fresco Logic xHCI host controller chip revision puts bad data into
the output endpoint context after a Reset Endpoint command.  It needs a
Configure Endpoint command (instead of a Set TR Dequeue Pointer command)
after the reset endpoint command.

Set up the input context before issuing the Reset Endpoint command so we
don't copy bad data from the output endpoint context.  The HW also can't
handle two commands queued at once, so submit the TRB for the Configure
Endpoint command in the event handler for the Reset Endpoint command.

Devices that stall on control endpoints before a configuration is selected
will not work under this Fresco Logic xHCI host controller revision.

This patch is for prototype hardware that will be given to other companies
for evaluation purposes only, and should not reach consumer hands.  Fresco
Logic's next chip rev should have this bug fixed.
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 an endpoint on a device under an xHCI host controller stalls, the
host controller driver must let the hardware know that the USB core has
successfully cleared the halt condition.  The HCD submits a Reset Endpoint
Command, which will clear the toggle bit for USB 2.0 devices, and set the
sequence number to zero for USB 3.0 devices.

The xHCI urb_enqueue will accept new URBs while the endpoint is halted,
and will queue them to the hardware rings.  However, the endpoint doorbell
will not be rung until the Reset Endpoint Command completes.

Don't queue a reset endpoint command for root hubs.  khubd clears halt
conditions on the roothub during the initialization process, but the roothub
isn't a real device, so the xHCI host controller doesn't need to know about the
cleared halt.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>