| Message ID | 20210415114856.4555-1-chris.chiu@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub | expand |
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
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
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
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
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
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
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
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
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
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 */