Message-ID: <CABTNMG0ye+APQA-vMpyfDhSOWdKtXD5BT=gBYYNXmfa_fiFfuA@mail.gmail.com>
Date:   Wed, 21 Apr 2021 00:54:48 +0800
From:   Chris Chiu <chris.chiu@...onical.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Greg KH <gregkh@...uxfoundation.org>, m.v.b@...box.com,
        hadess@...ess.net, linux-usb@...r.kernel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

On Tue, Apr 20, 2021 at 11:28 PM Alan Stern <stern@...land.harvard.edu> 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@...land.harvard.edu> 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

Powered by blists - more mailing lists