-
Douglas Anderson authored
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an extra reset to the probe path for the dwc2 USB controllers. This allowed proper detection of parameters even if the firmware had already used the USB part. Unfortunately, this extra reset is quite slow and is affecting boot speed. We can avoid the double-reset by skipping the extra reset that would happen just after the one we added. Logic that explains why this is safe: * As of the CL mentioned above, we now always call dwc2_core_reset() in dwc2_driver_probe() before dwc2_hcd_init(). * The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're guaranteed that dwc2_core_reset() was called before dwc2_hdc_init(). * dwc2_hdc_init() is the only caller that passes an irq other than -1 to dwc2_core_init(). Thus if dwc2_core_init() is called with an irq other than -1 we're guaranteed that dwc2_core_reset was called before dwc2_core_init(). ...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if irq is not < 0. Note that since "irq" wasn't used in the function dwc2_core_init() anyway and since select_phy was always set at exactly the same times we could avoid the reset, we remove "irq" and rename "select_phy" to "initial_setup" and adjust the callers accordingly. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
0fe239bc