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>

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>

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 patch (as1256) changes ehci-hcd and all the other drivers in the
EHCI family to make use of the new clear_tt_buffer callbacks.  When a
Clear-TT-Buffer request is in progress for a QH, the QH is not allowed
to be linked into the async schedule until the request is finished.
At that time, if there are any URBs queued for the QH, it is linked
into the async schedule.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is an update to the "usb-ehci-update-toggle-state-for-linked-qhs"
patch.  Since an HCD's endpoint_reset method can be called in
interrupt context, it mustn't assume that interrupts are enabled or
that it can sleep.

So we revert to the original way of refreshing QHs' toggle bits.  Now
the endpoint_reset method merely clears the toggle flag in the device
structure (as was done before) and starts an async QH unlink.  When the
QH is linked again, after the unlink finishes and an URB is queued,
the qh_refresh() routine will update the QH's toggle bit.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDavid <david@unsolicited.net>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1245) fixes a bug in ehci-hcd.  When an URB is queued
for an endpoint whose QH is already in the LINKED state, the QH
doesn't get refreshed.  As a result, if usb_clear_halt() was called
during the time that the QH was linked but idle, the data toggle value
in the QH doesn't get reset.

The symptom is that after a clear_halt, data gets lost and transfers
time out.  This problem is starting to show up now because the
"ehci-hcd unlink speedups" patch causes QHs with no queued URBs to
remain linked for a suitable time.

The patch utilizes the new endpoint_reset mechanism to fix the
problem.  When an endpoint is reset, the new method forcibly unlinks
the QH (if necessary) and safely updates the toggle value.  This
allows qh_update() to be simplified and avoids using usb_device's
toggle bits in a rather unintuitive way.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Tested-by: NDavid <david@unsolicited.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

All usb debugfs files should be behind the usb directory, not at the
root of debugfs.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64)

Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch (as1205) moves timer_action() from ehci.h to ehci-hcd.c and
makes it out-of-line.  Over the years it has grown too big to be inline
any more.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently ITDs are immediately recycled whenever their URB completes.
However, EHCI hardware can sometimes remember some ITD state.  This
means that when the ITD is reused before end-of-frame it may sometimes
cause the hardware to reference bogus state.

This patch defers reusing such ITDs by moving them into a new ehci member
cached_itd_list. ITDs resting in cached_itd_list are moved back into their
stream's free_list once scan_periodic() detects that the active frame has
elapsed.

This makes the snd_usb_us122l driver (in kernel since .28) work right
when it's hooked up through EHCI.

[ dbrownell@users.sourceforge.net: comment fixups ]
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Tested-by: NPhilippe Carriere <philippe-f.carriere@wanadoo.fr>
Tested-by: NFederico Briata <federicobriata@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1165) makes a few small changes in the logic used by
ehci-hcd when it encounters a controller error:

	Instead of printing out the masked status, it prints the
	original status as read directly from the hardware.

	It doesn't check for the STS_HALT status bit before taking
	action.  The mere fact that the STS_FATAL bit is set means
	that something bad has happened and the controller needs to
	be reset.  With the old code this test could never succeed
	because the STS_HALT bit was masked out from the status.

I anticipate that this will prevent the occasional "irq X: nobody cared"
problem people encounter when their EHCI controllers die.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This gets rid of an annoying warning in ehci-hcd.c when DEBUG isn't
enabled:

    warning: label 'err_debug' defined but not used

by moving it inside the already-existing #ifdef DEBUG, so that it
matches the goto.  And now my regular build is warning-free again.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch (as1147) fixes the remote-wakeup support for EHCI
controllers using the ARC/TDI "embedded-TT" core.  These controllers
turn off the RESUME bit by themselves when a port resume is complete;
hence we need to keep separate track of which ports are suspended or
in the process of resuming.

The patch also makes a couple of small improvements in ehci_irq(),
replacing reads of the command register with the value already stored
in a local variable.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NThomas Reitmayr <treitmayr@devbase.at>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd.  Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>  [2.6.27]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1145) removes the essentially useless driver-version
strings from ehci-hcd, ohci-hcd, and uhci-hcd.  It also unifies the
form of the banner lines they display upon loading and adds a missing
test for usb_disabled() to ehci-hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore remove
the dead code associated with !CONFIG_PPC_MERGE.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch is based on the following ideas:

1. Some usb devices (such as usb video class) have endpoints of high
   interval attribute, so reading "periodic" file need more debug buffer
   to accommodate the qh or itd schedule information.  For example, 4KB
   buffer is not enough for a single interrupt qh of 2ms period.

2. print a %p need 16 byte buffer on 64-bits arch, but 8 byte on 32-bits
   arch. Add a extra bonus for 64-bits arch.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I noticed that the "Refactor "if (handshake()) state = HC_STATE_HALT"
patch from earlier this year perpetuated a potential problem:  it can
mark the controller as halted when it's still running (but not acting
as, perhaps wrongly, expected).

That caused some hangs and crashes, rather than more polite failure
modes of a truly halted controller.  This patch forces a true halt,
and emits a (previously missing) diagnostic.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes some performance bugs observed with some workloads
when unlinking EHCI queue header (QH) descriptors from the async ring
(control/bulk schedule).

The mechanism intended to defer unlinking an empty QH (so there is no
penalty in common cases where it's quickly reused) was not working as
intended.  Sometimes the unlink was scheduled:

 - too quickly ... which can be a *strong* negative effect, since
   that QH becomes unavailable for immediate re-use;

 - too slowly ... wasting DMA cycles, usually a minor issue except
   for increased bus contention and power usage;

Plus there was an extreme case of "too slowly":  a logical error in the
IAA watchdog-timer conversion meant that sometimes the unlink never
got scheduled.

The fix replaces a simple counter with a timestamp derived from the
controller's 8 KHz microframe counter, and adjusts the timer usage
for some issues associated with HZ being less than 8K.

(Based on a patch originally by Alan Stern, and good troubleshooting
from  Leonid.)
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit fa38dfcc.

It wasn't really a regression and David and Alan are still working
through the issues reported.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1099) fixes a performance regression in ehci-hcd.  The
fundamental problem is that queue headers get removed from the
schedule too quickly, since the code checks for a counter advancing
rather than making an actual time-based check.  The latency involved
in removing the queue header and then relinking it can severely
degrade certain kinds of workloads.

The patch replaces a simple counter with a timestamp derived from the
controller's uframe value.  In addition, the delay for unlinking an
idle queue header is increased from 5 ms to 10 ms; since some
controllers (nVidia) have a latency of up to 1 ms for unlinking, this
reduces the relative impact from 20% to 10%.

Finally, a logical error left over from the IAA watchdog-timer
conversion is corrected.  Now the driver will always either unlink an
idle queue header or set up a timer to unlink it later.  The old code
would sometimes fail to do either.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch refactors some shutdown code so it can be shared between
ehci_stop() and ehci_shutdown().

This also fixes a couple potential bugs:
 - ehci_shutdown() was not locking ehci->lock before halting the HC.
 - ehci_shutdown() didn't disable the watchdog and IAA timers.
 - ehci_stop() was resetting the host controller when it may have been
   running, which the EHCI spec says "may result in undefined behavior".

ehci_stop() was calling port_power() to turn off the ports, which waited
20ms after applying the port change.  The msleep was for the case where
the HC might take 20ms to turn the ports on; since we're shutting them
off, we can avoid the msleep and just use ehci_turn_off_ports().

ehci_stop() doesn't need to clear the intr_enable register or revert
ownership of the companion controllers to the BIOS, because the host
controller reset should have done that.  There might be a buggy host
controller that doesn't follow the reset rules, but for now we assume
it's redundant code and remove it.

[ A subsequent patch will cancel the timers later ... this version
carries forward existing bugs where timers could get re-armed
after they're canceled. ]
Signed-off-by: NSarah Sharp <sarah.a.sharp@intel.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some EHCI fault paths with large control transfers aren't coded.  Avoid
problems by rejecting transfers that may need two qTDs (16+ KB).  This is
mostly paranoia; even 4 KB transfers are rare, and most HCDs use lower
limits (so it's unlikely anyone would ever try such a thing).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

It was pointed out that we found and fixed the cause of the "bogus"
fatal IRQ reports some time ago ... this patch removes the code
which was working around that bug ("status" got clobbered), and a
comment which needlessly confused folk reading this code.

This also includes a minor cleanup to the code which fixed that bug.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Refactor the EHCI "if (handshake()) state = HC_STATE_HALT" idiom,
which appears 4 times, by replacing it with calls to a new function
called handshake_on_error_set_halt().  Saves a few bytes too.
Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Minor cleanups to the EHCI code:  revision history is what source
code repositories should have.  Switch to a more standard way to
kick in verbose debugging -- don't be EHCI-specific.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Reviewed-by: NTzachi Perelstein <tzachi@marvell.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

The recent EHCI driver update to split the IAA watchdog timer out from
the other timers made several things work better, but not everything;
and it created a couple new issues in bugzilla.  Ergo this patch:

  - Handle a should-be-rare SMP race between the watchdog firing
    and (very late) IAA interrupts;

  - Remove a shouldn't-have-been-added WARN_ON() test;

  - Guard against one observed OOPS;

  - If this watchdog fires during clean HC shutdown, it should act
    as a NOP instead of interfering with the shutdown sequence;

  - Guard against silicon errata hypothesized by some vendors:
      * IAA status latch broken, but IAAD cleared OK;
      * IAAD wasn't cleared when IAA status got reported;

The WARN_ON is in bugzilla as 10168; the OOPS as 10078; these are
both regressions.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Tested-by: NGordon Farquharson <gordonfarquharson@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently, this setup:
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_HCD_PPC_OF=y

Will fail to build:
  CC      drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-hcd.c:1018:2: error: #error "missing bus glue for ehci-hcd"
make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1

ehci-hcd.c actually contains OF_PLATFORM_DRIVER glue, so error is bogus.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The previous fix for a "sparse" warning in ehci_urb_dequeue() was
incorrect.  After rescheduling interrupt transfers it returned the
URB's completion status, not status for the dequeue operation itself.

This patch resolves that issue, cleans up the code in the reschedule
path, and shrinks the object code by a dozen bytes.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

EHCI Glue driver for Intel IXP4XX EHCI USB controller
Signed-off-by: NVladimir Barinov <vbarinov@ru.mvista.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This adds device-tree-aware ehci-ppc-of driver.
The code is based on the ehci-ppc-soc driver by
Stefan Roese <sr@denx.de>.
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NStefan Roese <sr@denx.de>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some glue bits for the on-chip USB host controller in the Marvell Orion
family of ARM SoCs, which is basically EHCI compatible.
Signed-off-by: NTzachi Perelstein <tzachi@marvell.com>
Reviewed-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

fix warning:
drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an earlier one
drivers/usb/host/ehci-hcd.c:790:71: originally declared here
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1028) was mostly written by David Brownell; I made only
a few changes (extra log info and a small bug fix -- which might
account for why David's version had to be reverted).  It adds a new
watchdog timer to the ehci-hcd driver to be used exclusively for
detecting lost or missing IAA notifications.

Previously a shared timer had been used, which may have led to some
problems as reported by Christian Hoffmann.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We should not have multiple line files in sysfs, this moves the data to
debugfs instead, like the UHCI driver.
Signed-off-by: NTony Jones <tonyj@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A recent patch added software synchronization during EHCI startup,
so ports aren't switched away from the companion controllers after
resets have started.  This patch adds a short delay letting hardware
finish that port switching before any new resets begin ... so both
ends of that hardware race window are closed.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Dave Miller <davem@davemloft.net>
Cc: Dely Sy <dely.l.sy@intel.com>
Cc: stable <stable@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as999) fixes a problem that sometimes shows up when host
controller driver modules are loaded in the wrong order.  If ehci-hcd
happens to initialize an EHCI controller while the companion OHCI or
UHCI controller is in the middle of a port reset, the reset can fail
and the companion may get very confused.  The patch adds an
rw-semaphore and uses it to keep EHCI initialization and port resets
mutually exclusive.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Cc: David Miller <davem@davemloft.net>
Cc: Dely L Sy <dely.l.sy@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as954) implements a suggestion of David Brownell's.  Now
the host controller drivers are responsible for linking and unlinking
URBs to/from their endpoint queues.  This eliminates the possiblity of
strange situations where usbcore thinks an URB is linked but the HCD
thinks it isn't.  It also means HCDs no longer have to check for URBs
being dequeued before they were fully enqueued.

In addition to the core changes, this requires changing every host
controller driver and the root-hub URB handler.  For the most part the
required changes are fairly small; drivers have to call
usb_hcd_link_urb_to_ep() in their urb_enqueue method,
usb_hcd_check_unlink_urb() in their urb_dequeue method, and
usb_hcd_unlink_urb_from_ep() before giving URBs back.  A few HCDs make
matters more complicated by the way they split up the flow of control.

In addition some method interfaces get changed.  The endpoint argument
for urb_enqueue is now redundant so it is removed.  The unlink status
is required by usb_hcd_check_unlink_urb(), so it has been added to
urb_dequeue.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
CC: Olav Kongas <ok@artecdesign.ee>
CC: Tony Olech <tony.olech@elandigitalsystems.com>
CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit 196705c9.  It was
reported to cause a regression by Daniel Exner, and Arjan van de Ven
points out that we actually already have infrastructure in place for
setting limits on acceptable DMA latency that would be the much more
correct fix for the problem with some Broadcom EHCI controllers.

Fixed up trivial conflicts due to the changes to support big-endian host
controller descriptors in drivers/usb/host/{ehci-sched.c,ehci.h}.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>