This patch (as1385) adds a "do_wakeup" parameter to the pci_suspend
method used by PCI-based host controller drivers.  ehci-hcd in
particular needs to know whether or not to enable wakeup when
suspending a controller.  Although that information is currently
available through device_may_wakeup(), when support is added for
runtime suspend this will no longer be true.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1393) converts several of the single-bit fields in
struct usb_hcd to atomic flags.  This is for safety's sake; not all
CPUs can update bitfield values atomically, and these flags are used
in multiple contexts.

The flag fields that are set only during registration or removal can
remain as they are, since non-atomic accesses at those times will not
cause any problems.

(Strictly speaking, the authorized_default flag should become atomic
as well.  I didn't bother with it because it gets changed only via
sysfs.  It can be done later, if anyone wants.)
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch will enable Per-port event feature defined in EHCI 1.1
addendum. This feature addresses an issue where HCD is currently
required to read and parse PORTSC for all enabled root hub ports. With
this patch, the overhead will be reduced.
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

With this patch, the LPM capable EHCI host controller can put device
into L1 sleep state which is a mode that can enter/exit quickly, and
reduce power consumption.
Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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

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

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

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

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

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

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

1. There are two msleep calls inside two spin lock sections, need to unlock
   and lock again after msleep.
2. Save a extra status reg setting.
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1321) fixes a problem with EHCI and UHCI root-hub
suspends: If the suspend occurs while a port is trying to resume, the
resume doesn't finish and simply gets lost.  When remote wakeup is
enabled, this is undesirable behavior.

The patch checks first to see if any port resumes are in progress, and
if they are then it fails the root-hub suspend with -EBUSY.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

No need to check ehci->debug twice.

Found-by: Sergei Shtylyov sshtylyov@ru.mvista.com
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In order for the dbgp driver to survive suspend/resume, on every ehci
resume operation the debug controller must get re-initialized.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: dbrownell@users.sourceforge.net
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the EHCI debug port is initialized and in use, the EHCI host
controller driver must follow two rules.

1) If the EHCI host driver issues a controller reset, the debug
   controller driver re-initialization must get called after the reset
   is completed.

2) The EHCI host driver should ignore any requests to the physical
   EHCI debug port when the EHCI debug port is in use.

The code to check for the debug port was moved from ehci_pci_reinit()
to ehci_pci_setup because it must get called prior to ehci_reset()
which will clear the debug port registers.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: dbrownell@users.sourceforge.net
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch was previously discussed in the following thread:
http://thread.gmane.org/gmane.linux.usb.general/19472/focus=19484

On the OMAP3 device the usbhost controller is in a separate internal
power-domain. So when the usbhost is inactive or suspend is called,
we can disable clocks and power-down the usbhost to save power.

Recently we found that after calling ehci_bus_suspend() and disabling
the usbhost clocks we would see the ehci watchdog timer event fire. This
was causing a kernel panic because the usbhost controllers clocks were
disabled and inside the watchdog timer function the clocks were not
being re-enabled, so when the ehci registers were accessed this resulted
in a CPU data-abort.

To avoid this panic, per recommendation from Alan Stern (see above thread), we
make sure any pending timer events (that may have been scheduled by calling
ehci_work within the ehci_bus_suspend() function) are deleted before returning.
Signed-off-by: NFei Yang <fei.yang@motorola.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
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 controller device is where we want this sysfs file, especially as
the dev pointer is about to go away...

Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.

There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.

Quote from original descriprion:

The 440EPx USB 2.0 Host controller is an EHCI compliant controller.  In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI.  An USB 2.0 Host controller will
contain one or more ports.  For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller.  If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed.  When an ehci driver
is loaded, it explicitly takes control of the ports.  If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not.  If it
is high speed, the driver retains control of the port.  If it is not,
the driver explicitly gives the companion controller control of the
port.

The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:

http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html

and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2

The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: NVitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

For function ehci_bus_resume()
- Added flag resume_needed
  No need to wait for 20ms if no port was suspended

- Change mdelay to msleep

- release and reacquire the spinlock around mdelay
Signed-off-by: Nvikram pandita <vikram.pandita@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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 (as1097) fixes a bug in the remote-wakeup handling in
ehci-hcd.  The driver currently does not keep track of whether the
change-suspend feature is enabled for each port; the feature is
automatically reset the first time it is read.  But recent changes to
the hub driver require that the feature be read at least twice in
order to work properly.

A bit-vector is added for storing the change-suspend feature values.
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>

This patch (as1096) fixes an annoying problem: When a full-speed or
low-speed device is plugged into an EHCI controller, it fails to
enumerate at high speed and then is handed over to the companion
controller.  But usbcore logs a misleading and unwanted error message
when the high-speed enumeration fails.

The patch adds a new HCD method, port_handed_over, which asks whether
a port has been handed over to a companion controller.  If it has, the
error message is suppressed.
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>

Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* endianness annotations
* endianness fixes
* missing get_unaligned/put_unaligned

It's pretty much all over the place, changes to different files are independent.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Serial-parts-Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch (as1072) fixes some recently-introduced compile problems
that show up in ehci-hcd when CONFIG_PM is turned off.

	PORT_WAKE_BITS needs to be defined always.

	ehci_port_power() is called during initialization by all the
	EHCI variants other than the PCI version, in which it is
	"defined but not used".  So add a call to it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When a USB device is suspended, whether or not it is enabled for
remote wakeup depends on the device_may_wakeup() setting.  The setting
is then saved in the do_remote_wakeup flag.

Later on, however, the device_may_wakeup() value can change because of
user activity.  So when testing whether a suspended device is or
should be enabled for remote wakeup, we should always test
do_remote_wakeup instead of device_may_wakeup().  This patch (as1076)
makes that change for root hubs in several places.

The patch also adjusts uhci-hcd so that when an autostopped controller
is suspended, the remote wakeup setting agrees with the value recorded
in the root hub's do_remote_wakeup flag.

And the patch adjusts ehci-hcd so that wakeup events on selectively
suspended ports (i.e., the bus itself isn't suspended) don't turn on
the PME# wakeup signal.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
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>

This patch (as1047) removes the USB_PERSIST Kconfig option, enabling
it permanently.  It also prevents the power/persist attribute from
being created for hub devices; there's no point in having it since
USB-PERSIST is always turned on for hubs.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1044) causes EHCI port handover for non-high-speed
devices to occur during every root-hub resume, not just in cases where
the controller lost power or was reset.  This is necessary because:

	When some machines go into suspend, they remove power from
	on-board USB devices while retaining suspend current for USB
	controllers.

	The user might well unplug a USB device while the system is
	suspended and then plug it back in before resuming.

A corresponding change is made to the core resume routine; now
high-speed root hubs will always be resumed when the system wakes up,
even if they were suspended before the system went to sleep.  If this
weren't done then EHCI port handover wouldn't work, since it is called
when the EHCI root hub is resumed.

Finally, a comment is added to the hub driver explaining the khubd has
to be freezable; if it weren't frozen then it could interfere with
port handover.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch, suggested by Alan Stern, fixes the hung USB issues
on my notebook from suspend/resume cycles.

It does so by eliminating some confusion about the internal state
machine associated with unlinking from the EHCI async schedule ring,
which caused a recent regression:

  http://bugzilla.kernel.org/show_bug.cgi?id=10345Signed-off-by: NMark Lord <mlord@pobox.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some of the "EHCI ports reset forever" problems may be explained by
code paths which wrongly flagged resets as complete.  This removes
two such paths; the ehci_hub_status_data() path should be the only one
to have an effect, since it was already properly flagged on the other
path.  (Issue noted by Minhyoung Kim <a9a9@lge.com>.)
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1031) adds a short delay to the bus-suspend routine in
ehci-hcd.  Without it some devices disconnect when they should
suspend.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1030b) moves a del_timer_sync() call outside the scope of a
spinlock, where it could cause a deadlock, and adds a new
del_timer_sync() call for the new IAA watchdog timer (it was omitted
by mistake).
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>

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>

This patch hands over the port to the companion when the
hub_port_connect_change fails.
Signed-off-by: NBalaji Rao <balajirrao@gmail.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Convert from class_device to device for drivers/usb/core.
Signed-off-by: NTony Jones <tonyj@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix the various misspellings of "system", controller", "interrupt" and
"[un]necessary".
Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>

Root hubs can't be resumed if their parent controller device is still
suspended.  This patch (as925) adds a check for that condition in
hcd_bus_resume() and prevents it from being treated as a fatal
controller failure.

ehci-hcd is updated to add the corresponding test.  Unnecessary
debugging messages are removed from uhci-hcd and dummy-hcd.  The
error return code from dummy-hcd is changed to -ESHUTDOWN, the same as
the others.  ohci-hcd doesn't need any changes.

Suspend handling in the non-PCI host drivers is somewhat hit-and-miss.
This patch shouldn't have any effect on them.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

According to the USB Specification Revision 2.0 chapter 11.12.5
a hub experiencing an over-current condition must place all
affected ports in the powered-off state. It seems that some root
hubs need port power to be cycled by software in order to get back
to normal functionality after an over-current condition ... like
the EHCI implementation on an MPC8343E.
Signed-off-by: NChristian Engelmayer <christian.engelmayer@frequentis.com>
Signed-off-by: NDavid Brownell <david-b@pacbell.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as895) fixes up a loose end in the port-handover code for
the USB-Persist facility.  A special case occurs when a high-speed
device is attached to a port which the user has designated to run at
full-speed only; the port must be disabled before the handover can
take place.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as887) changes the way ehci-hcd and ohci-hcd handle a loss
of VBUS power during suspend.  In order for the USB-persist facility
to work correctly, it is necessary for low- and full-speed devices
attached to a high-speed port to be handed back to the companion
controller during resume processing.

This entails three changes: adding code to ehci-hcd to perform the
handover, removing code from ohci-hcd to turn off ports during
root-hub reinit, and adding code to ohci-hcd to turn on ports during
PCI controller resume.  (Other bus glue resume methods for platforms
supporting high-speed controllers would need a similar change, if any
existed.)
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>