On Tue, Apr 20, 2021 at 11:28 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Apr 20, 2021 at 03:14:56PM +0800, Chris Chiu wrote: > > 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 > > Here 3-4 is problematic RealTek hub, right? Yes. > > > 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 > > Then 3-4.3 is another hub plugged into the Realtek hub, and 3-4.3.1 (the > device being suspended and resumed) is plugged into that other hub. > > I'm concerned about devices that are plugged directly into the Realtek > hub. For example, did you try allowing the 3-4.3 hub in the experiment > above to suspend and resume? > > Alan Stern The WD19 dock has 2 hubs 0bda:5487 (USB3.0) and 0bda:0487 (superspeed). There're 5 exposed USB ports (3 Type A + 2 Type C). Lower speed ports connect to a sub-hub (3-4.3) of the problematic hub (3-4). The other ports such as HDMI/DisplayPort, Gigabit Ethernet and Type C ports are connected to 0bda:0478. So I can't connect any USB devices directly to hub 3-4. I'm only certain that the direct child (3-4.3) of the hub 0bda:5487 can't runtime suspend. But what really matters to me is that all connected devices (3-4.3.x) can runtime suspend. Chris
