Revert "USB: set hub's default autosuspend delay as 0"

Certain USB-C devices are failing to enumerate if the bus
transitions from active to suspend between connection and enumeration.

When a USB-C accessory is inserted in a phone and is detected by the
CC lines, the controller driver is loaded and the only devices present
on the bus are the root hubs, until the device enumerations.
As a result, a suspend transition between device connection and
enumeration is very likely.

This change leaves the hub autosuspend set to the usbcore.autosuspend
value so a value can be set high enough to prevent this race.

This reverts:
commit 596d789a211d ("USB: set hub's default autosuspend delay as 0")

  This patch sets hub device's default autosuspend delay as 0 to
  speedup bus suspend, see comments in code for details.

Bug: 71936484
Change-Id: If9b50c52fdbbece154ca9adf559cd93db89fb0f3
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Signed-off-by: Andrew Chant <achant@google.com>

1 files changed, 0 insertions, 35 deletions

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 0df07e7a6d5f..df3c9ed536f0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1693,41 +1693,6 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 	hdev = interface_to_usbdev(intf);
 
 	/*
-	 * Set default autosuspend delay as 0 to speedup bus suspend,
-	 * based on the below considerations:
-	 *
-	 * - Unlike other drivers, the hub driver does not rely on the
-	 *   autosuspend delay to provide enough time to handle a wakeup
-	 *   event, and the submitted status URB is just to check future
-	 *   change on hub downstream ports, so it is safe to do it.
-	 *
-	 * - The patch might cause one or more auto supend/resume for
-	 *   below very rare devices when they are plugged into hub
-	 *   first time:
-	 *
-	 *   	devices having trouble initializing, and disconnect
-	 *   	themselves from the bus and then reconnect a second
-	 *   	or so later
-	 *
-	 *   	devices just for downloading firmware, and disconnects
-	 *   	themselves after completing it
-	 *
-	 *   For these quite rare devices, their drivers may change the
-	 *   autosuspend delay of their parent hub in the probe() to one
-	 *   appropriate value to avoid the subtle problem if someone
-	 *   does care it.
-	 *
-	 * - The patch may cause one or more auto suspend/resume on
-	 *   hub during running 'lsusb', but it is probably too
-	 *   infrequent to worry about.
-	 *
-	 * - Change autosuspend delay of hub can avoid unnecessary auto
-	 *   suspend timer for hub, also may decrease power consumption
-	 *   of USB bus.
-	 */
-	pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
-
-	/*
 	 * Hubs have proper suspend/resume support, except for root hubs
 	 * where the controller driver doesn't have bus_suspend and
 	 * bus_resume methods.