GitHub PushEvent at 2014-05-06 05:35:39
Repository: Blaze.Kernel-S5
Actor: GuneetAtwal
Payload: {"shas":[["420c3b84d6294977a8abe97b9531f9313353f9e8","4d12f06cff3725783b352157673a720bc67c4afe@chromium.org","usb: core: don't try to reset_device() a port that got just disconnected\n\ncommit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream.\n\nThe USB hub driver's event handler contains a check to catch SuperSpeed\ndevices that transitioned into the SS.Inactive state and tries to fix\nthem with a reset. It decides whether to do a plain hub port reset or\ncall the usb_reset_device() function based on whether there was a device\nattached to the port.\n\nHowever, there are device/hub combinations (found with a JetFlash\nTranscend mass storage stick (8564:1000) on the root hub of an Intel\nLynxPoint PCH) which can transition to the SS.Inactive state on\ndisconnect (and stay there long enough for the host to notice). In this\ncase, above-mentioned reset check will call usb_reset_device() on the\nstale device data structure. The kernel will send pointless LPM control\nmessages to the no longer connected device address and can even cause\nseveral 5 second khubd stalls on some (buggy?) host controllers, before\nfinally accepting the device's fate amongst a flurry of error messages.\n\nThis patch makes the choice of reset dependent on the port status that\nhas just been read from the hub in addition to the existence of an\nin-kernel data structure for the device, and only proceeds with the more\nextensive reset if both are valid.\n\nSigned-off-by: Julius Werner <jwerner@chromium.org>\nSigned-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Julius Werner",true]],"size":1,"ref":"refs/heads/upstream_kk","head":"420c3b84d6294977a8abe97b9531f9313353f9e8"}