usb: core: don't try to reset_device() a port that got just disconnected

The USB hub driver's event handler contains a check to catch
SuperSpeed
devices that transitioned into the SS.Inactive state and
tries to fix
them with a reset. It decides whether to do a plain hub
port reset or
call the usb_reset_device() function based on whether
there was a device
attached to the port.

However, there are device/hub
combinations (found with a JetFlash
Transcend mass storage stick
(8564:1000) on the root hub of an Intel
LynxPoint PCH) which can
transition to the SS.Inactive state on
disconnect (and stay there long
enough for the host to notice). In this
case, above-mentioned reset
check will call usb_reset_device() on the
stale device data structure.
The kernel will send pointless LPM control
messages to the no longer
connected device address and can even cause
several 5 second khubd
stalls on some (buggy?) host controllers, before
finally accepting the
device's fate amongst a flurry of error messages.

This patch makes the
choice of reset dependent on the port status that
has just been read
from the hub in addition to the existence of an
in-kernel data structure
for the device, and only proceeds with the more
extensive reset if both
are valid.

Signed-off-by: Julius Werner
<jwerner@chromium.org>
Signed-off-by: Sarah Sharp
<sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

idea is taken here -
https://github.com/varunchitre15/thunderzap_xl/commit/92e383ec476d33c067157bbab63905ecd7627d83