This patch (as1556) works around a bug in the Philips ISP1562 EHCI
controller.  Although the controller claims to support frame-list
lengths smaller than the default of 1024 for its periodic schedule, in
fact smaller values don't work.  A new quirk flag is added to indicate
when the bug is present, and if it is then the schedule size is left
at the default value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The upcoming Intel Lynx Point chipset includes an xHCI host controller
that can have ports switched from the EHCI host controller, just like
the Intel Panther Point xHCI host.  This time, ports from both EHCI
hosts can be switched to the xHCI host controller.  The PCI config
registers to do the port switching are in the exact same place in the
xHCI PCI configuration registers, with the same semantics.

Hooray for shipping patches for next-gen hardware before the current gen
hardware is even available for purchase!

This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

This patch (as1545) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

This fixes Bugzilla #42728.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
Tested-by: NOleksij Rempel (fishor) <bug-track@fisher-privat.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlessandro Rubini <rubini@gnudd.com>
Acked-by: NGiancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1489) works around a hardware bug in MosChip EHCI
controllers.  Evidently when one of these controllers increments the
frame-index register, it changes the three low-order bits (the
microframe counter) before changing the higher order bits (the frame
counter).  If the register is read at just the wrong time, the value
obtained is too low by 8.

When the appropriate quirk flag is set, we work around this problem by
reading the frame-index register a second time if the first value's
three low-order bits are all 0.  This gives the hardware a chance to
finish updating the register, yielding the correct value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NJason N Pitt <jpitt@fhcrc.org>
CC: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1483) improves the ehci-hcd driver family by getting rid
of the reliance on the hcd->state variable.  It has no clear owner and
it isn't protected by the usual HCD locks.  In its place, the patch
adds a new, private ehci->rh_state field to record the state of the
root hub.

Along the way, the patch removes a couple of lines containing
redundant assignments to the state variable.  Also, the QUIESCING
state simply gets changed to the RUNNING state, because the driver
doesn't make any distinction between them.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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>

The two first HC capability registers (CAPLENGTH and HCIVERSION)
are defined as one 8-bit and one 16-bit register. Most HC
implementations have selected to treat these registers as part
of a 32-bit register, giving the same layout for both big and
small endian systems.

This patch adds a new quirk, big_endian_capbase, to support
controllers with big endian register interfaces that treat
HCIVERSION and CAPLENGTH as individual registers.
Signed-off-by: NJan Andersson <jan@gaisler.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/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.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit b7d5b439.
It conflicts with commit baab93af "USB:
EHCI: ASPM quirk of ISOC on AMD Hudson" and merging the two just doesn't
work properly.

Cc: Andiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/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.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a msleep with spin lock held during ehci pci suspend, which will
cause kernel BUG: scheduling while atomic. Fix that.

[  184.139620] BUG: scheduling while atomic: kworker/u:11/416/0x00000002
[  184.139632] 4 locks held by kworker/u:11/416:
[  184.139640]  #0:  (events_unbound){+.+.+.}, at: [<c104ddd4>] process_one_work+0x1b3/0x4cb
[  184.139669]  #1:  ((&entry->work)){+.+.+.}, at: [<c104ddd4>] process_one_work+0x1b3/0x4cb
[  184.139686]  #2:  (&__lockdep_no_validate__){+.+.+.}, at: [<c127cde3>] __device_suspend+0x2c/0x154
[  184.139706]  #3:  (&(&ehci->lock)->rlock){-.-...}, at: [<c132f3d8>] ehci_pci_suspend+0x35/0x7b
[  184.139725] Modules linked in: serio_raw pegasus joydev mrst_gfx(C) battery
[  184.139748] irq event stamp: 52
[  184.139753] hardirqs last  enabled at (51): [<c14fdaac>] mutex_lock_nested+0x258/0x293
[  184.139766] hardirqs last disabled at (52): [<c14fe7b4>] _raw_spin_lock_irqsave+0xf/0x3e
[  184.139777] softirqs last  enabled at (0): [<c10371c1>] copy_process+0x3d2/0x109d
[  184.139789] softirqs last disabled at (0): [<  (null)>]   (null)
[  184.139802] Pid: 416, comm: kworker/u:11 Tainted: G         C  2.6.37-6.3-adaptation-oaktrail #37
[  184.139809] Call Trace:
[  184.139820]  [<c102eeff>] __schedule_bug+0x5e/0x65
[  184.139829]  [<c14fbca5>] schedule+0xac/0xc4c
[  184.139840]  [<c11d4845>] ? string+0x37/0x8b
[  184.139853]  [<c1044f21>] ? lock_timer_base+0x1f/0x3e
[  184.139863]  [<c14fe7da>] ? _raw_spin_lock_irqsave+0x35/0x3e
[  184.139876]  [<c1061590>] ? trace_hardirqs_off+0xb/0xd
[  184.139885]  [<c14fccdc>] schedule_timeout+0x283/0x2d9
[  184.139896]  [<c104516f>] ? process_timeout+0x0/0xa
[  184.139906]  [<c14fcd47>] schedule_timeout_uninterruptible+0x15/0x17
[  184.139916]  [<c104566a>] msleep+0x10/0x16
[  184.139926]  [<c132f316>] ehci_adjust_port_wakeup_flags+0x69/0xf6
[  184.139937]  [<c132f3eb>] ehci_pci_suspend+0x48/0x7b
[  184.139946]  [<c1326587>] suspend_common+0x52/0xbb
[  184.139956]  [<c1326625>] hcd_pci_suspend+0x26/0x28
[  184.139967]  [<c11e7182>] pci_pm_suspend+0x5f/0xd0
[  184.139976]  [<c127ca3a>] pm_op+0x5d/0xf0
[  184.139986]  [<c127ceac>] __device_suspend+0xf5/0x154
[  184.139996]  [<c127d2c8>] async_suspend+0x16/0x3a
[  184.140006]  [<c1058f54>] async_run_entry_fn+0x89/0x111
[  184.140016]  [<c104deb6>] process_one_work+0x295/0x4cb
[  184.140026]  [<c1058ecb>] ? async_run_entry_fn+0x0/0x111
[  184.140036]  [<c104e3d0>] worker_thread+0x17f/0x298
[  184.140045]  [<c104e251>] ? worker_thread+0x0/0x298
[  184.140055]  [<c105277f>] kthread+0x64/0x69
[  184.140064]  [<c105271b>] ? kthread+0x0/0x69
[  184.140075]  [<c1002efa>] kernel_thread_helper+0x6/0x1a
Signed-off-by: NYin Kangkai <kangkai.yin@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <dbrownell@users.sourceforge.net>
CC: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

AMD Hudson also needs the same ASPM quirk as SB800
Signed-off-by: NAlex He <alex.he@amd.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When ASPM PM Feature is enabled on UMI link, devices that use ISOC stream of
data transfer may be exposed to longer latency causing less than optimal per-
formance of the device. The longer latencies are normal and are due to link
wake time coming out of low power state which happens frequently to save
power when the link is not active.
The following code will make exception for certain features of ASPM to be by
passed and keep the logic normal state only when the ISOC device is connected
and active. This change will allow the device to run at optimal performance
yet minimize the impact on overall power savings.
Signed-off-by: NAlex He <alex.he@amd.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Tested on MacBookAir3,1.  Without this, we get EPROTO errors when
fetching device config descriptors.
Signed-off-by: NBrian Tarricone <brian@tarricone.org>
Reported-by: NBenoit Gschwind <gschwind@gnu-log.net>
Tested-by: NEdgar Hucek <gimli@dark-green.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds support for the EHCI IP block present on the Intel
CE4100.
Signed-off-by: NDirk Brandewie <dirk.brandewie@gmail.com>
CC: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On AMD SB700/SB800/Hudson-2/3 platforms, USB EHCI controller may read/write
to memory space not allocated to USB controller if there is longer than
normal latency on DMA read encountered. In this condition the exposure will
be encountered only if the driver has following format of Periodic Frame
List link pointer structure:

For any idle periodic schedule, the Frame List link pointers that have the
T-bit set to 1 intending to terminate the use of frame list link pointer
as a physical memory pointer.

Idle periodic schedule Frame List Link pointer shoule be in the following
format to avoid the issue:

Frame list link pointer should be always contains a valid pointer to a
inactive QHead with T-bit set to 0.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We have to do so due to HW limitation.
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1405) fixes a small bug in ehci-hcd's isochronous
scheduler.  Not all EHCI controllers are PCI, and the code shouldn't
assume that they are.  Instead, introduce a special flag for
controllers which need to delay iso scheduling for full-speed devices
beyond the scheduling threshold.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: David Brownell <david-b@pacbell.net>
CC: stable <stable@kernel.org>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

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>

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>

I've been running with this patch on my Niagara2 boxes for some time
and have not seen any ill effects yet.  Maybe we can stash this into
the USB tree to get exposure for some time in -next and if anything
crops up we can simply revert?
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

a quirky chipset needs periodic schedules to run for a minimum
time before they can be disabled again. This enforces the requirement
with a time stamp and a calculated delay
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Cc: stable <stable@kernel.org>
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>

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>

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

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 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>

This patch (as1237) changes the way the PCI host controller drivers
avoid retaining bogus hardware states during resume-from-hibernation.
Previously we had reset the hardware as part of preparing to reinstate
the memory image.  But we can do better now with the new PM framework,
since we know exactly which resume operations are from hibernation.

The pci_resume method is changed to accept a flag indicating whether
the system is resuming from hibernation.  When this flag is set, the
drivers will reset the hardware to get rid of any existing state.

Similarly, the pci_suspend method is changed to remove the
pm_message_t argument.  It's no longer needed, since no special action
has to be taken when preparing to reinstate the memory image.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1236) converts the USB PCI power management routines
over to the new PM framework.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Replace all DMA_31BIT_MASK macro with DMA_BIT_MASK(31)

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>

If a USB PCI controller is behind a cardbus bridge, we are trying to
restore its configuration registers too early, before the cardbus
bridge is operational.  To fix this, call pci_restore_state() from
usb_hcd_pci_resume() and remove usb_hcd_pci_resume_early() which is
no longer necessary (the configuration spaces of USB controllers that
are not behind cardbus bridges will be restored by the PCI PM core
with interrupts disabled anyway).

This patch fixes the regression from 2.6.28 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12659

[ Side note: the proper long-term fix is probably to just force the
  unplug event at suspend time instead of doing a plug/unplug at resume
  time, but this patch is fine regardless  - Linus ]
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NMiles Lane <miles.lane@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit a0d4922d
(USB: fix up suspend and resume for PCI host controllers) attempted
to fix the suspend-resume of PCI USB controllers, but unfortunately
it did that incorrectly and interrupts are left enabled by the USB
controllers' ->suspend_late() callback as a result.  This leads to
serious problems during suspend which are very difficult to debug.

Fix the issue by removing the ->suspend_late() callback of PCI
USB controllers and moving the code from there to the ->suspend()
callback executed with interrupts enabled.  Additionally, make
the ->resume() callback of PCI USB controllers execute
pci_enable_wake(dev, PCI_D0, false) to disable wake-up from the
full power state (PCI_D0).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Tested-by: N"Jeff Chua" <jeff.chua.linux@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Zdenek Kabelac" <zdenek.kabelac@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1199) changes the initial wakeup settings for PCI USB
host controllers.  The controllers are marked as capable of waking the
system, but wakeup is not enabled by default.

It turns out that enabling wakeup for USB host controllers has a lot
of bad consequences.  As the simplest example, if a USB mouse or
keyboard is unplugged immediately after the computer is put to sleep,
the unplug will cause the system to wake back up again!  We are better
off marking them as wakeup-capable and leaving wakeup disabled.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NRafael J. Wysocki <rjw@sisk.pl>
CC: David Brownell <david-b@pacbell.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1193b) enables wakeup during initialization for all PCI
host controllers, and it removes some code (and comments!) that are no
longer needed now that the PCI core automatically initializes wakeup
settings for all new devices.

The idea is that the bus should initialize wakeup, and the bus glue
or controller driver should enable it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1192) rearranges the USB PCI host controller suspend and
resume and resume routines:

	Use pci_wake_from_d3() for enabling and disabling wakeup,
	instead of pci_enable_wake().

	Carry out the actual state change while interrupts are
	disabled.

	Change the order of the preparations to agree with the
	general recommendation for PCI devices, instead of
	messing around with the wakeup settings while the device
	is in D3.

		In .suspend:
			Call the underlying driver to disable IRQ
				generation;
			pci_wake_from_d3(device_may_wakeup());
			pci_disable_device();

		In .suspend_late:
			pci_save_state();
			pci_set_power_state(D3hot);
			(for PPC_PMAC) Disable ASIC clocks

		In .resume_early:
			(for PPC_PMAC) Enable ASIC clocks
			pci_set_power_state(D0);
			pci_restore_state();

		In .resume:
			pci_enable_device();
			pci_set_master();
			pci_wake_from_d3(0);
			Call the underlying driver to reenable IRQ
				generation

	Add the necessary .suspend_late and .resume_early method
	pointers to the PCI host controller drivers.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch is required for all AMD SB600 revisions to avoid USB subsystem hang
symptom. The USB subsystem hang symptom is observed when the system has
multiple USB devices connected to it. In some cases a USB hub may be required
to observe this symptom.

Reported in bugzilla as #11599, the similar patch for SB700 old revision is:
commit b09bc6cbReported-by: Nraffaele <ralfconn@tele2.it>
Tested-by: NRoman Mamedov <roman@rm.pp.ru>
Signed-off-by: NShane Huang <shane.huang@amd.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch is required for AMD SB700 south bridge revision A12 and A13 to avoid
USB subsystem hang symptom. The USB subsystem hang symptom is observed when the
system has multiple USB devices connected to it. In some cases a USB hub may be
required to observe this symptom.

This patch works around the problem by correcting the internal register setting
that will help by changing the behavior of the internal logic to avoid the
USB subsystem hang issue. The change in the behavior of the logic does not
impact the normal operation of the USB subsystem.
Reported-by: NVolker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>
Tested-by: NVolker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NLibin Yang <libin.yang@amd.com>
Cc: stable <stable@kernel.org>
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>