[PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[chris.chiu]

From: Chris Chiu <chris.chiu@canonical.com>

Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=5487 Rev= 1.47
S:  Manufacturer=Dell Inc.
S:  Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the target port of the hub. The port
will be unresponsive and placed in unknown state. The hub_activate
invoked during resume will fail to get the port stautus with -EPROTO.
Then all devices connected to the hub will never be found and probed.

The USB_PORT_FEAT_SUSPEND is not really necessary due to the
"global suspend" in USB 2.0 spec. It's only for many hub devices
which don't relay wakeup requests from the devices connected to
downstream ports. For this realtek hub, there's no problem waking
up the system from connected keyboard.

This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.

Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
---

Changelog:
  v3:
    - Do not mislead usbcore that the quirky hub is really suspended.
      return -EIO for quirky hub instead of doing USB_PORT_FEAT_SUSPEND
    - Revise the commit message
  v2:
    Since the 0bda:5413 is the hub device connects to upstream hub
    0bda:5487, the upstream hub which fails the USB_PORT_FEAT_SUSPEND
    is the target this patch really wants to quirk.
    - Fix the quirk target from the connected hub device to the
      upstream hub
    - Correct the usb info of the target hub in the commit message
    - Revise the description of the quirk

 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 drivers/usb/core/hub.c                          | 10 +++++++---
 drivers/usb/core/quirks.c                       |  5 +++++
 include/linux/usb/quirks.h                      |  3 +++
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..1bb22a9ea5ba 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5682,6 +5682,9 @@
 					pause after every control message);
 				o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
 					delay after resetting its port);
+				p = USB_QUIRK_NO_SET_FEAT_SUSPEND (Hub can't
+					handle set-port-feature-suspend request
+					correctly);
 			Example: quirks=0781:5580:bk,0a5c:5834:gij
 
 	usbhid.mousepoll=
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 7f71218cc1e5..a73e3931aecd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3328,9 +3328,13 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
 	 * Therefore we will turn on the suspend feature if udev or any of its
 	 * descendants is enabled for remote wakeup.
 	 */
-	else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
-		status = set_port_feature(hub->hdev, port1,
-				USB_PORT_FEAT_SUSPEND);
+	else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0) {
+		if (hub->hdev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
+			status = -EIO;
+		else
+			status = set_port_feature(hub->hdev, port1,
+					USB_PORT_FEAT_SUSPEND);
+	}
 	else {
 		really_suspend = false;
 		status = 0;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 76ac5d6555ae..9f373579bf9e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -138,6 +138,9 @@ static int quirks_param_set(const char *value, const struct kernel_param *kp)
 			case 'o':
 				flags |= USB_QUIRK_HUB_SLOW_RESET;
 				break;
+			case 'p':
+				flags |= USB_QUIRK_NO_SET_FEAT_SUSPEND;
+				break;
 			/* Ignore unrecognized flag characters */
 			}
 		}
@@ -406,6 +409,8 @@ static const struct usb_device_id usb_quirk_list[] = {
 
 	/* Realtek hub in Dell WD19 (Type-C) */
 	{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+	{ USB_DEVICE(0x0bda, 0x5487), .driver_info =
+			USB_QUIRK_NO_SET_FEAT_SUSPEND },
 
 	/* Generic RTL8153 based ethernet adapters */
 	{ USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 5e4c497f54d6..ac469d446c78 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -72,4 +72,7 @@
 /* device has endpoints that should be ignored */
 #define USB_QUIRK_ENDPOINT_IGNORE		BIT(15)
 
+/* Hub can't handle set-port-feature-suspend request correctly */
+#define USB_QUIRK_NO_SET_FEAT_SUSPEND		BIT(16)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
2.20.1

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Greg KH]

On Thu, Apr 15, 2021 at 07:48:56PM +0800, chris.chiu@canonical.com wrote:
> From: Chris Chiu <chris.chiu@canonical.com>
> 
> Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
> after the system resumes from suspend with remote wakeup enabled
> device connected:
> [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
> [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

How does other operating systems handle this?  The hardware seems like
it does not follow the USB spec, how did it get "certified"?

> Information of this hub:
> T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
> D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
> P:  Vendor=0bda ProdID=5487 Rev= 1.47
> S:  Manufacturer=Dell Inc.
> S:  Product=Dell dock
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> 
> The failure results from the ETIMEDOUT by chance when turning on
> the suspend feature for the target port of the hub. The port
> will be unresponsive and placed in unknown state. The hub_activate
> invoked during resume will fail to get the port stautus with -EPROTO.
> Then all devices connected to the hub will never be found and probed.
> 
> The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> "global suspend" in USB 2.0 spec. It's only for many hub devices
> which don't relay wakeup requests from the devices connected to
> downstream ports. For this realtek hub, there's no problem waking
> up the system from connected keyboard.
> 
> This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.

Can you make this only be allowed for hubs?  But why doesn't the nomal
"this can not suspend properly" bit work for this?  We have that for
other USB devices already.

thanks,

greg k-h

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Thu, Apr 15, 2021 at 8:32 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Apr 15, 2021 at 07:48:56PM +0800, chris.chiu@canonical.com wrote:
> > From: Chris Chiu <chris.chiu@canonical.com>
> >
> > Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
> > after the system resumes from suspend with remote wakeup enabled
> > device connected:
> > [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> > [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
> > [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> > [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
>
> How does other operating systems handle this?  The hardware seems like
> it does not follow the USB spec, how did it get "certified"?
>
I agree. All usb hubs that claim to support Selective Scan should handle
SetPortFeature (PORT_SUSPEND) w/o problems. As I know, the Windows
usb device driver should submit an Idle Request before it's really going to
suspend, and the bus driver will "selectively" suspend the port.

One thing worth mentioning here, I never hit the hub_ext_port_status -71
problem if I resume by waking up from the keyboard connected to the hub.
But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
of that port while resuming. In normal cases, they are 0507:0000.
 I don't know how to SetPortFeature() with setting the status change bit only.
Or maybe it's just some kind of timing issue of the
idle/suspend/resume signaling.

Chris

> > Information of this hub:
> > T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
> > D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
> > P:  Vendor=0bda ProdID=5487 Rev= 1.47
> > S:  Manufacturer=Dell Inc.
> > S:  Product=Dell dock
> > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> > I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> > I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> >
> > The failure results from the ETIMEDOUT by chance when turning on
> > the suspend feature for the target port of the hub. The port
> > will be unresponsive and placed in unknown state. The hub_activate
> > invoked during resume will fail to get the port stautus with -EPROTO.
> > Then all devices connected to the hub will never be found and probed.
> >
> > The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> > "global suspend" in USB 2.0 spec. It's only for many hub devices
> > which don't relay wakeup requests from the devices connected to
> > downstream ports. For this realtek hub, there's no problem waking
> > up the system from connected keyboard.
> >
> > This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.
>
> Can you make this only be allowed for hubs?  But why doesn't the nomal
> "this can not suspend properly" bit work for this?  We have that for
> other USB devices already.
>
> thanks,
>
> greg k-h

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Alan Stern]

On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> One thing worth mentioning here, I never hit the hub_ext_port_status -71
> problem if I resume by waking up from the keyboard connected to the hub.

I thought you said earlier that the port got into trouble while it was 
suspending, not while it was resuming.  You wrote:

> [ 2789.679812] usb 3-4-port3: can't suspend, status -110

So if the problem occurs during suspend, how can it be possible to avoid 
the problem by taking some particular action later while resuming?

> But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
> of that port while resuming. In normal cases, they are 0507:0000.

The 0004 bit of wPortChange means that the suspend status has changed; 
the port is no longer suspended because the device attached to that port 
(your keyboard) issued a wakeup request.

>  I don't know how to SetPortFeature() with setting the status change bit only.

You can't.  Only the hub itself can set the wPortChange bits.

> Or maybe it's just some kind of timing issue of the
> idle/suspend/resume signaling.

Not timing.  It's because you woke the system up from the attached 
keyboard.

Alan Stern

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Fri, Apr 16, 2021 at 2:46 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > problem if I resume by waking up from the keyboard connected to the hub.
>
> I thought you said earlier that the port got into trouble while it was
> suspending, not while it was resuming.  You wrote:
>
> > [ 2789.679812] usb 3-4-port3: can't suspend, status -110
>
> So if the problem occurs during suspend, how can it be possible to avoid
> the problem by taking some particular action later while resuming?
>

The ETIMEDOUT is still there, but the port can resume w/o problems and I
don't really know what the hub did. I can only reset_resume the hub to bring it
back if I'm not waking up from the connected keyboard.

> > But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
> > of that port while resuming. In normal cases, they are 0507:0000.
>
> The 0004 bit of wPortChange means that the suspend status has changed;
> the port is no longer suspended because the device attached to that port
> (your keyboard) issued a wakeup request.
>
> >  I don't know how to SetPortFeature() with setting the status change bit only.
>
> You can't.  Only the hub itself can set the wPortChange bits.
>
> > Or maybe it's just some kind of timing issue of the
> > idle/suspend/resume signaling.
>
> Not timing.  It's because you woke the system up from the attached
> keyboard.
>
> Alan Stern

Got it. I'm just confused by the USB 2.0 spec 11.24.2.7.2 that
"Hubs may allow setting of the status change bits with a SetPortFeature()
 request for diagnostic purposes."

So for this case, I think USB_QUIRK_RESET_RESUME would be a
better option to at least bring back the port. Any suggestion about what
kind of test I can do on this hub? Thanks

Chris

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Alan Stern]

On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote:
> On Fri, Apr 16, 2021 at 2:46 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > > problem if I resume by waking up from the keyboard connected to the hub.
> >
> > I thought you said earlier that the port got into trouble while it was
> > suspending, not while it was resuming.  You wrote:
> >
> > > [ 2789.679812] usb 3-4-port3: can't suspend, status -110
> >
> > So if the problem occurs during suspend, how can it be possible to avoid
> > the problem by taking some particular action later while resuming?
> >
> 
> The ETIMEDOUT is still there, but the port can resume w/o problems and I
> don't really know what the hub did. I can only reset_resume the hub to bring it
> back if I'm not waking up from the connected keyboard.

What if two devices are plugged into the hub, only one of them is 
runtime suspended, and you need to runtime resume that device?  Then you 
can't do a reset-resume of the hub, because the hub isn't suspended.

> > > But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
> > > of that port while resuming. In normal cases, they are 0507:0000.
> >
> > The 0004 bit of wPortChange means that the suspend status has changed;
> > the port is no longer suspended because the device attached to that port
> > (your keyboard) issued a wakeup request.
> >
> > >  I don't know how to SetPortFeature() with setting the status change bit only.
> >
> > You can't.  Only the hub itself can set the wPortChange bits.
> >
> > > Or maybe it's just some kind of timing issue of the
> > > idle/suspend/resume signaling.
> >
> > Not timing.  It's because you woke the system up from the attached
> > keyboard.
> >
> > Alan Stern
> 
> Got it. I'm just confused by the USB 2.0 spec 11.24.2.7.2 that
> "Hubs may allow setting of the status change bits with a SetPortFeature()
>  request for diagnostic purposes."

Yeah, I don't think very many hubs actually do that.

> So for this case, I think USB_QUIRK_RESET_RESUME would be a
> better option to at least bring back the port. Any suggestion about what
> kind of test I can do on this hub? Thanks

I'm not sure what you're proposing.

If (as mentioned above) the hub doesn't handle the 
Set-Port-Feature(suspend) request properly, then we should avoid issuing 
that request.  Which means runtime suspend attempts should not be 
allowed, as in your most recent patch.

Alan Stern

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Fri, Apr 16, 2021 at 11:39 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote:
> > On Fri, Apr 16, 2021 at 2:46 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > > > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > > > problem if I resume by waking up from the keyboard connected to the hub.
> > >
> > > I thought you said earlier that the port got into trouble while it was
> > > suspending, not while it was resuming.  You wrote:
> > >
> > > > [ 2789.679812] usb 3-4-port3: can't suspend, status -110
> > >
> > > So if the problem occurs during suspend, how can it be possible to avoid
> > > the problem by taking some particular action later while resuming?
> > >
> >
> > The ETIMEDOUT is still there, but the port can resume w/o problems and I
> > don't really know what the hub did. I can only reset_resume the hub to bring it
> > back if I'm not waking up from the connected keyboard.
>
> What if two devices are plugged into the hub, only one of them is
> runtime suspended, and you need to runtime resume that device?  Then you
> can't do a reset-resume of the hub, because the hub isn't suspended.
>
> > > > But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
> > > > of that port while resuming. In normal cases, they are 0507:0000.
> > >
> > > The 0004 bit of wPortChange means that the suspend status has changed;
> > > the port is no longer suspended because the device attached to that port
> > > (your keyboard) issued a wakeup request.
> > >
> > > >  I don't know how to SetPortFeature() with setting the status change bit only.
> > >
> > > You can't.  Only the hub itself can set the wPortChange bits.
> > >
> > > > Or maybe it's just some kind of timing issue of the
> > > > idle/suspend/resume signaling.
> > >
> > > Not timing.  It's because you woke the system up from the attached
> > > keyboard.
> > >
> > > Alan Stern
> >
> > Got it. I'm just confused by the USB 2.0 spec 11.24.2.7.2 that
> > "Hubs may allow setting of the status change bits with a SetPortFeature()
> >  request for diagnostic purposes."
>
> Yeah, I don't think very many hubs actually do that.
>
> > So for this case, I think USB_QUIRK_RESET_RESUME would be a
> > better option to at least bring back the port. Any suggestion about what
> > kind of test I can do on this hub? Thanks
>
> I'm not sure what you're proposing.
>
> If (as mentioned above) the hub doesn't handle the
> Set-Port-Feature(suspend) request properly, then we should avoid issuing
> that request.  Which means runtime suspend attempts should not be
> allowed, as in your most recent patch.
>
> Alan Stern

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.

I didn't like RESET_RESUME because runtime PM would not work on the quirked
device. 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?

Chris

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Alan Stern]

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

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Mon, Apr 19, 2021 at 10:19 PM Alan Stern <stern@rowland.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

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

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Alan Stern]

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@rowland.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?

> 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

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

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