> Hi Ming, I also find this problem at my platform. > (At chipidea controller, the resume signal will be ended about 21ms > automatically) > My test is echo auto to keyboard (hub in int), then press key to wakeup it, the system doesn't enter suspend. > Neither delay 30ms at hub_events, nor revert your patch > (596d789a211d134dc5f94d1e5957248c204ef850) can work. > > This problem may exist after my patch > (6273f1810f95f4deeb2f0d6810f301726ad32308) > > The first log is for this problem, the second one without problem > due to console output occupy much times and resume bit is cleared. > > -------------------------------First Log------------------------ > mx_usb 2184000.usb: Wakeup interrupt occurs imx_controller_resume > mxs_phy 20c9000.usbphy: Connect line between phy and controller > ci_hdrc ci_hdrc.0: port 1 remote wakeup > imx_usb 2184000.usb: at the end of imx_controller_resume, ret = 0 > usb usb1: usb wakeup-resume > usb usb1: usb auto-resume > ci_hdrc ci_hdrc.0: resume root hub > hub 1-0:1.0: hub_resume > ci_hdrc ci_hdrc.0: GetStatus port:1 status 100014c5 8 ACK POWER sig=k > SUSPEND RESUME PE CONNECT > hub 1-0:1.0: port 1: status 0107 change 0000 > hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 > hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 > hub 1-0:1.0: hub_suspend This hub_suspend is expected or not? If it is expected, below error may not be avoided, since usb_port_resume still doesn't be called, and Get_PORT_STATUS is either to be called, then the ehci->resuming_ports will not be cleared. > usb usb1: bus auto-suspend, wakeup 1 > ci_hdrc ci_hdrc.0: suspend root hub > ci_hdrc ci_hdrc.0: suspend failed because a port is resuming > usb usb1: bus suspend fail, err -16 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
