intel/lynxpoint: xhci: Revert suspend/resume changes

I have been attempting to work around USB3 issues that appear in the
kernel with hacks in the firmware, but this is resulting in more
headaches in the kernel.

Instead remove all the work that was being done at resume time and undo
the change that was issuing a warm reset to all ports at suspend time.

The bad device behavior will be dealt with at the kernel level to
handle devices that get stuck in polling state after enable/disable
sequence.

BUG=chrome-os-partner:22754
BRANCH=falco,peppy,wolf,leon
TEST=manual:

suspend/resume with several misbehaving devices:
Kingston USB3 Media Reader
Transcend USB3 Media Reader
Various ADATA USB3 drives
Various Kingston USB3 sticks

Original-Change-Id: I0894454af42d2ced456fe0da921d74c9e74902d0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170107
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c2abb4d0dad6ed00e1e230d604c4c0a76eb4eef7)

Change-Id: Ib215d9c230f90a1c9f34bf29254bb9feec28c67e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170578
[pm: rebase to master branch of coreboot upstream]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6016
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
intel/lynxpoint: Work around XHCI resume issues

When USB3 devices are attached while in suspend, or two USB3 devices
that are both plugged in are switched to the other port while in
suspend the kernel does not seem to notice this -- despite the cold
attach status bit.  This results in the devices showing up in the USB
list at the old enumerated device numbers and higher layers continuing
to think they are present but not reseponding.

With the kernel workaround to deal with devices that are logically
disconnected it is possible for firmware to send a warm port reset to
devices that are in this state and then the kernel will see them disappear
and handle it properly.

This same issue exists in the EFI firmware on the Whitetip Mountain 2
reference board so it is not specifically a coreboot bug.  If this
behavior is fixed in the kernel then this workaround could be removed
since it is in RW firmware.

BUG=chrome-os-partner:22818
BRANCH=falco,peppy,wolf,leon
TEST=manual:

1) attach two USB3 devices
2) suspend system
3) switch the ports that the USB3 devices are attatched to
4) resume system
5) confirm that the devices are re-enumerated and come up properly

Original-Change-Id: Ifba3ffc94a06dc0b2436d7d7d464d824657362af
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 203d200268f4af6445224962190cbc66ad2a83e4)

Change-Id: I54fd2847ee25a60f25c2cefebdc1a3c18455464a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170579
[pm: rebase to master branch of coreboot upstream]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6017
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
intel/lynxpoint: Allow to always route USB3 ports to XHCI

This will make USB keyboards connected to USB3 ports work
in libpayload on Beltino.

BUG=chrome-os-partner:23396
BRANCH=none
TEST=Use USB keyboard on Beltino in dev mode screen

Change-Id: I70b03d733bd9e4c8be5673b48bd2196effa8a5e7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173640
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
[pm: rebase to master branch of coreboot upstream]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6018
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>