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

[Chris Chiu <chris.chiu@canonical.com>]

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