On Fri, Apr 16, 2021 at 2:46 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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
