On 4/18/2023 8:55 PM, Greg KH wrote: > On Tue, Apr 18, 2023 at 07:38:17PM +0530, Basavaraj Natikar wrote: >> xHC system resume time may increase due to a 120ms delay. > I'm sorry, but I can not understand this sentence. Is the delay 120ms > too long? Or too short? Or will it change to be always at least 120ms? > Or something else? Each USB controller while xhci_resumes by default takes 120 ms if there is no activity on the ports or no ports connected. Therefore, if there are more USB controllers on the system, 120 ms per controller will add delay to system resume. This patch will prevent 120 ms for each XHCI controller during system resume. > >> A PME# signal >> will trigger the xHC host to resume runtime, and the host must wait for a >> missed U3 LFPS wake signal before re-checking for port activity. It may >> be necessary to wait only for auto-resume cases. Add a check only for >> runtime resume to avoid the delay for other PM events so that the resume >> time can be improved. Once XHCI controller in runtime suspended state (D3), on USB device hotplug controller will resume (D0) and check for pending port events if no events, wait for 120 ms to re-check for port activity i.e. the first wake signalling failed is handled in below changes. https://lore.kernel.org/all/20210311115353.2137560-3-mathias.nyman@xxxxxxxxxxxxxxx/ This check adds delay to system resume case as well, which may be only required for runtime resume (auto resume) case. So added an extra check to handle the runtime resume case only. Will retry to reword accordingly as above. If you have any input, please let me know. Thanks, -- Basavaraj > I also can not understand these last two sentences, can you try to > reword it a bit differently? > > thanks, > > greg k-h
