On Tue, Apr 13, 2021 at 12:29:35AM +0530, Pratham Pratap wrote: > Hi, > > The current implementation of usb_port_resume > (usb_reset_and_verify_device()) can take up-to 60 secs in worst-case > scenario if the device (let's say the device went bad and is unresponsive to > any setup packets) connected went into runtime suspend and resumed back. Is > it fine to have a configurable upper bound? Since it can induce delay in the > overall system resume if the host is waking up from PM suspend. > > [USB port resume in worst case ] > > usb_port_resume() > finish_port_resume() > usb_get_std_status() > usb_get_status() > USB_CTRL_GET_TIMEOUT : 5 sec > > > usb_reset_and_verify_device() > SET_CONFIG_TRIES 3 (use_new_scheme: 2 /old scheme: 1) > hub_port_init() > GET_DESCRIPTOR_TRIES 2 > operations < 3 > > 2*2*3 (12) * 5(USB_CTRL_GET_TIMEOUT) = 60 sec I'm not sure where you got that 2*2*3 from. Is this a real problem? How often have you observed this to happen? If you know any particular devices that die like this when they are suspended, have you tried adding them to the USB quirks list with the USB_QUIRK_RESET_RESUME flag? There is the usb "persist" parameter. If you set it to false, what happens to this delay? Alan Stern
