The USB 3.0 specification says that sending a Set Feature or Clear
Feature for U1/U2 Enable is not a valid request when the device is in
the Default or Addressed state.  It is only valid when the device is in
the Configured state.

The original LPM patch attempted to disable LPM after the device had
been reset by hub_port_init(), before it had the configuration
reinstalled.  The TI hub I tested with did not fail the Clear Feature
U1/U2 Enable request that khubd sent while it was in the addressed
state, which is why I didn't catch it.

Move the LPM disable before the device reset, so that we can send the
Clear Feature U1/U2 Enable successfully, and balance the LPM disable
count.

Also delete any calls to usb_enable_lpm() on error paths that lead to
re-enumeration.  The calls will fail because the device isn't
configured, and it's not useful to balance the LPM disable count because
the usb_device is about to be destroyed before re-enumeration.

Fix the early exit path ("done" label) to call usb_enable_lpm() to
balance the LPM disable count.

Note that calling usb_reset_and_verify_device() with an unconfigured
device may fail on the first call to usb_disable_lpm().  That's because
the LPM disable count is initialized to 0 (LPM enabled), and
usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to
a device in the Addressed state.  The next patch will fix that.

This commit should be backported to kernels as old as 3.5, that contain
the commit 8306095f "USB: Disable USB
3.0 LPM in critical sections."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org