Description of problem: There is a mouse attached in the xHCI port. Then plug out this mouse and plug to UHCI port after system go into hibernation. This mouse will random be identified after system wakeup from hibernation. During s4 wakeup, xHCI driver will cleanup this disconnect mouse (not connect to xHCI port). This will delay s4 wakeup process and UHCI root hub will goto auto suspend. Usb hub threads will be called to handle usb controller root hub's event after S4 wakeup completed. However, this are too many usb controllers to ensure EHCI and UHCI hub threads execute order. Once, EHCI giveback port to UHCI before UHCI hub event check. UHCI will try to enumerate this mouse with UHCI run bit not set. Which will cause control transfer fail during enumeration phase. In order to fix this issues, set UHCI root hub auto suspend delay value larger. UHCI run bit will be set after wakeup from S4 and mouse will be identified. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 测试环境： 1) 带有IOE和onboard UHCI的主板(USB controller尽量多), 任意Linux OS 2) 测试设备：mouse 测试Case： 1 S4插拔测试： 1） 启动系统后将Mouse插在xHCI上面，让系统进入S4 2） 在S4状态下，拔掉插入在xHCI上面的mouse, 然后插入到USB 2.0 port下面. 然后唤醒系统 3） S4 resume回来进入系统，移动mouse并查看Mouse是否能够正常工作。 2 S0插拔测试 在S0下面多次插拔接在USB2.0 port上面的mouse,并查看其是否可以正常识别和工作。 Actual results: Expected results: 在各种测试case下面，device都可以正识别，mouse能够正常工作即可以认为pass Additional info:
merged: https://gitee.com/anolis/cloud-kernel/pulls/843