On Mon, Apr 19, 2021 at 10:19 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote: > > Sorry that I didn't make myself clear. I found that if I applied RESET_RESUME > > quirk on the problematic hub, the Set-Port-Feature(suspend) timeout error > > disappeared. SInce the timeout is not happening for each suspend by default, > > I suspect maybe reset-resume take everything back to clean state for the hub > > and the Set-Port-Feature(suspend) can be taken care of w/o problems. > > Okay, that's a good solution for system suspend. > > > I didn't like RESET_RESUME because runtime PM would not work on the quirked > > device. > > A more interesting question is whether it will work for devices plugged > into the hub. Even though the hub won't be runtime suspended, the > things attached to it might be. > > > But if the Set-Port-Feature(suspend) can't be handled and > > skipped, I can't > > expect the runtime PM to work for all devices connected to the hub either. > > Is that right? If what I proposed in the patch can not get better > > result than existing > > quirk, I think using the RESET_RESUME would be a better option. Any suggestions? > > Try the RESET_RESUME quirk and see how well it works with runtime > suspend. > > Alan Stern [ 453.064346] usb 3-4: finish reset-resume [ 453.192387] usb 3-4: reset high-speed USB device number 2 using xhci_hcd [ 453.339916] usb 3-4: USB quirks for this device: 2 Seems that even w/ the RESET_RESUME enabled, the connected device still can runtime suspend/resume. That's acceptable to me. I'll send the patch with the reset-resume quirk later. [ 626.081068] usb 3-4.3.1: usb auto-suspend, wakeup 0 [ 632.552071] usb 3-4.3.1: usb auto-resume [ 632.617467] usb 3-4.3.1: Waited 0ms for CONNECT [ 632.617471] usb 3-4.3.1: finish resume Chris
