move both ohci-au1xxx and ehci-au1xxx over to dev_pm_ops.

Tested on Au1200.
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Platform device support was merged earlier, but support for boards to
customize the devflags aspect of the controller was not.  We want this on
Blackfin systems to control the bus width, but might as well expose all of
the fields while we're at it.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The Intel Moorestown EHCI controller supports non-standard HOSTPCx register
extension. This register controls the LPM behaviour and controls the behaviour
of each USB port.
Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
Signed-off-by: NAlek Du <alek.du@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The ehci_qh structure merged hw and sw together which is not good:
1. More and more items are being added into ehci_qh, the ehci_qh software
   part are unnecessary to be allocated in DMA qh_pool.
2. If HCD has local SRAM, the sw part will consume it too, and it won't
   bring any benefit.
3. For non-cache-coherence system, the entire ehci_qh is uncachable, actually
   we only need the hw part to be uncacheable. Spliting them will let the sw
   part to be cacheable.
Signed-off-by: NAlek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Basically the io watchdog is only useful for those quirk HCDs. For most
good ones, it only brings unnecessary wakeups.  At least, I know the
Intel EHCI HCDs should turn off the flag.
Signed-off-by: NAlek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb_hcd_endpoint_reset() may be called in atomic context and must not
sleep.  So make whci-hcd's endpoint_reset() asynchronous.  URBs
submitted while the reset is in progress will be queued (on the std
list) and transfers will resume once the reset is complete.
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add ehci support for w90p910 platform.
Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

vfree() does it's own NULL checking,so no need for check before
calling it.
Signed-off-by: NFigo.zhang <figo1802@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Interrupt transfers are submitted to the xHCI hardware using the same TRB
type as bulk transfers.  Re-use the bulk transfer enqueueing code to
enqueue interrupt transfers.

Interrupt transfers are a bit different than bulk transfers.  When the
interrupt endpoint is to be serviced, the xHC will consume (at most) one
TD.  A TD (comprised of sg list entries) can take several service
intervals to transmit.  The important thing for device drivers to note is
that if they use the scatter gather interface to submit interrupt
requests, they will not get data sent from two different scatter gather
lists in the same service interval.

For now, the xHCI driver will use the service interval from the endpoint's
descriptor (bInterval).  Drivers will need a hook to poll at a more
frequent interval.  Set urb->interval to the interval that the xHCI
hardware will use.
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>

The xHCI hardware reports the number of bytes untransferred for a given
transfer buffer.  If the hardware reports a bytes untransferred value
greater than the submitted buffer size, we want to play it safe and say no
data was transferred.  If the driver considers a short packet to be an
error, remember to set -EREMOTEIO.
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>

Make sure that the driver that submitted the URB considers a short packet
an error before setting -EREMOTEIO during a short control 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>

Make sure that the amount of data the xHC says was transmitted is less
than or equal to the size of the requested transfer buffer.  Before, if
the host controller erroneously reported that the number of bytes
untransferred was bigger than the buffer in the URB, urb->actual_length
could be set to a very large size.

Make sure urb->actual_length <= urb->transfer_buffer_length.
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>

On a successful transfer, urb->td is freed before the URB is ready to be
given back to the driver.  Don't touch urb->td after it's freed.  This bug
would have only shown up when xHCI debugging was turned on, and the freed
memory was quickly reused for something else.
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>

The 0.95 xHCI spec says that non-control endpoints will be halted if a
babble is detected on a transfer.  The 0.96 xHCI spec says all types of
endpoints will be halted when a babble is detected.  Some hardware that
claims to be 0.95 compliant halts the control endpoint anyway.

When a babble is detected on a control endpoint, check the hardware's
output endpoint context to see if the endpoint is marked as halted.  If
the control endpoint is halted, a reset endpoint command must be issued
and the transfer ring dequeue pointer needs to be moved past the stopped
transfer.  Basically, we treat it as if the control endpoint had stalled.

Handle bulk babbling endpoints as if we got a completion event with a
stall completion code.
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>

Use trb_comp_code instead of getting the completion code from the transfer
event every time.
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 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 a control endpoint stalls, the next control transfer will clear the
stall.  The USB core doesn't call down to the host controller driver's
endpoint_reset() method when control endpoints stall, so the xHCI driver
has to do all its stall handling for internal state in its interrupt handler.

When the host stalls on a control endpoint, it may stop on the data phase
or status phase of the control transfer.  Like other stalled endpoints,
the xHCI driver needs to queue a Reset Endpoint command and move the
hardware's control endpoint ring dequeue pointer past the failed control
transfer (with a Set TR Dequeue Pointer or a Configure Endpoint command).

Since the USB core doesn't call usb_hcd_reset_endpoint() for control
endpoints, we need to do this in interrupt context when we get notified of
the stalled transfer.  URBs may be queued to the hardware before these two
commands complete.  The endpoint queue will be restarted once both
commands complete.
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>

Full speed devices have varying max packet sizes (8, 16, 32, or 64) for
endpoint 0.  The xHCI hardware needs to know the real max packet size
that the USB core discovers after it fetches the first 8 bytes of the
device descriptor.

In order to fix this without adding a new hook to host controller drivers,
the xHCI driver looks for an updated max packet size for control
endpoints.  If it finds an updated size, it issues an evaluate context
command and waits for that command to finish.  This should only happen in
the initialization and device descriptor fetching steps in the khubd
thread, so blocking should be fine.
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>

Set the max packet size for the default control endpoint on high speed
devices to be 64 bytes.  High speed devices always have a max packet size
of 64 bytes.  There's no use setting it to eight for the initial 8 byte
descriptor fetch and then issuing (and waiting for) an evaluate context
command to update it to 64 bytes for the subsequent control transfers.

The USB core guesses that the max packet size on a full speed control
endpoint is 64 bytes, and then updates it after the first 8-byte
descriptor fetch.  Change the initial setup for the xHCI internal
representation of the full speed device to have a 64 byte max packet size.
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>

Refactor out the code issue, wait for, and parse the event completion code
for a configure endpoint command.  Modify it to support the evaluate
context command, which has a very similar submission process.  Add
functions to copy parts of the output context into the input context
(which will be used in the evaluate context command).
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>

Use the virtual address of the memory hardware uses, not the address for
the container of that memory.
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>

Different sections of the xHCI 0.95 specification had opposing
requirements for the chain bit in a link transaction request buffer (TRB).
The chain bit is used to designate that adjacent TRBs are all part of the
same scatter gather list that should be sent to the device.  Link TRBs can
be in the middle, or at the beginning or end of these chained TRBs.

Sections 4.11.5.1 and 6.4.4.1 both stated the link TRB "shall have the
chain bit set to 1", meaning it is always chained to the next TRB.
However, section 4.6.9 on the stop endpoint command has specific cases for
what the hardware must do for a link TRB with the chain bit set to 0.  The
0.96 specification errata later cleared up this issue by fixing the
4.11.5.1 and 6.4.4.1 sections to state that a link TRB can have the chain
bit set to 1 or 0.

The problem is that the xHCI cancellation code depends on the chain bit of
the link TRB being cleared when it's at the end of a TD, and some 0.95
xHCI hardware simply stops processing the ring when it encounters a link
TRB with the chain bit cleared.

Allow users who are testing 0.95 xHCI prototypes to set a module parameter
(link_quirk) to turn on this link TRB work around.  Cancellation may not
work if the ring is stopped exactly on a link TRB with chain bit set, but
cancellation should be a relatively uncommon case.
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>

SL811 Device detected after removal used to be working in linux-2.6.22
but then broke somewhere between 2.6.22 and 2.6.28. Current
hub_port_connect_change() in drivers/usb/core/hub.c won't call
usb_disconnect() in case the SL811 driver sets portstatus
USB_PORT_FEAT_CONNECTION upon removal.
AFAIK the SL811 has only a combined Device Insert/Remove
detection bit, therefore use a count to distinguish insert or remove.
Signed-Off-By: NMichael Hennerich <hennerich@blackfin.uclinux.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NUwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

trivial: fix typo "for for" in multiple files
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

trivial: OHCI: Fix typo in a comment
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Change default debugfs directory as mounting point for debugging
UHCI(Universal Host Controller Interface driver) for USB.

As we all know, We need change default directory for consistency of
debugfs by Greg K-H
Signed-off-by: NGeunSik Lim <geunsik.lim@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1274) simplifies the counting of transaction-error
retries.  Now we will count up from 0 to QH_XACTERR_MAX instead of
down from QH_XACTERR_MAX to 0.

The patch also fixes a small bug: qh->xacterr was not getting
initialized for interrupt endpoints.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NMatthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1273) fixes two(!) bugs introduced by the new
Clear-TT-Buffer implementation in ehci-hcd.

	It is now possible for an idle QH to have some URBs on its
	queue -- this will happen if a Clear-TT-Buffer is pending for
	the QH's endpoint.  Consequently we should not issue a warning
	when someone tries to unlink an URB from an idle QH; instead
	we should process the request immediately.

	The refcounts for QHs could get messed up, because
	submit_async() would increment the refcount when calling
	qh_link_async() and qh_link_async() would then refuse to link
	the QH into the schedule if a Clear-TT-Buffer was pending.
	Instead we should increment the refcount only when the QH
	actually is added to the schedule.  The current code tries to
	be clever by leaving the refcount alone if an unlink is
	immediately followed by a relink; the patch changes this to an
	unconditional decrement and increment (although they occur in
	the opposite order).
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Tested-by: NManuel Lauss <manuel.lauss@gmail.com>
Tested-by: NMatthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This fixes up the dev_pm_ops conversion and wires up the callbacks needed
for hibernation.
Signed-off-by: NYoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Correct the xHCI code to handle stalls on USB endpoints.  We need to move
the endpoint ring's dequeue pointer past the stalled transfer, or the HW
will try to restart the transfer the next time the doorbell is rung.

Don't attempt to clear a halt on an endpoint if we haven't seen a stalled
transfer for it.  The USB core will attempt to clear a halt on all
endpoints when it selects a new configuration.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Adds support for controllers that use 64-byte contexts.  The following context
data structures are affected by this: Device, Input, Input Control, Endpoint,
and Slot.  To accommodate the use of either 32 or 64-byte contexts, a Device or
Input context can only be accessed through functions which look-up and return
pointers to their contained contexts.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Make sure the xHCI output device context is 64-byte aligned.  Previous
code was using the same structure for both the output device context and
the input control context.  Since the structure had 32 bytes of flags
before the device context, the output device context wouldn't be 64-byte
aligned.  Define a new structure to use for the output device context and
clean up the debugging for these two structures.

The copy of the device context in the input control context does *not*
need to be 64-byte aligned.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Allocates and initializes the scratchpad buffer array (XHCI 4.20).  This is an
array of 64-bit DMA addresses to scratch pages that the controller may use
during operation.  The number of pages is specified in the "Max Scratchpad
Buffers" field of HCSPARAMS2.  The DMA address of this array is written into
slot 0 of the DCBAA.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is a work around for a bug in the SuperSpeed Endpoint Companion Descriptor
parsing code.  It fails in some corner cases, which means ep->ss_ep_comp may be
NULL.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Pass back a babble error when this error code is seen in the transfer event TRB.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The xHCI host controller can be programmed to retry a transfer a certain number
of times per endpoint before it passes back an error condition to the host
controller driver.  The xHC will return an error code when the error count
transitions from 1 to 0.  Programming an error count of 3 means the xHC tries
the transfer 3 times, programming it with a 1 means it tries to transfer once,
and programming it with 0 means the HW tries the transfer infinitely.

We want isochronous transfers to only be tried once, so set the error count to
one.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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

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

Add more debugging to the irq handler, slot context initialization, ring
operations, URB cancellation, and MMIO writes.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>