On Wed, Mar 21, 2012 at 11:01:12AM +0800, Elric Fu wrote: > 2012/3/21 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>: > > On Tue, Mar 20, 2012 at 12:44:03PM +0800, Elric Fu wrote: > >> 2012/3/17 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>: > > If the USB 2.0 hub really isn't responding to the Set Address command, > > there's not much we can do about it. I think there is one xHCI driver > > bug where it won't issue a command abort when the Set Address command > > times out, but you wouldn't see any other xHCI commands work after that > > happens. You would also see messages like: > > > > xhci_warn(xhci, "%s while waiting for address device command\n", > > timeleft == 0 ? "Timeout" : "Signal"); > > > > There's some trickiness to the solution to the set address timeout > > handling (you need a flag to make it so the driver doesn't ring the > > command ring doorbell or issue a new command abort until you've received > > confirmation of the first canceled command), so I haven't had time to > > get around to it yet. However, if you're not seeing the Timeout > > messages, the device probably is responding to the control transfer. > > > > You're right. I did't find any message about timeout. > > Actually, I have found the xHCI driver has the bug when the address device > command timeout before. According to the xHCI spec, when the address > device command timeout is happened, the driver have to abort the command > ring and wait the event about the command ring stopped. Otherwise, the > command ring will wait the response from the device all along. I am waiting for > a special device to duplicate the issue and confirm the solution is correct. Yes, you're correct that the xHCI driver is supposed to issue a command abort when the set address command times out. Does your solution include making sure that another command submission doesn't ring the doorbell? Feel free to send your patch before you get your special device. I have an old VIA USB 3.0 hub I can test the set address timeout on. It stops responding to set addresses after several disconnect/connect cycles. > > Maybe you need to ask the firmware team if there's anything special that > > needs to be done to initialize the integrated USB 2.0 hub after a resume > > from suspend? Maybe it needs a Get Descriptor control transfer before > > the Set Address control transfer? Or it could be something completely > > different. At this point, I'm not really sure how to fix the issue with > > the USB 2.0 hub. > > Maybe I need to determine the port link state of the port attached by the > integrated usb 2.0 hub. I worry that the port link state is transition to other > states except for U0 after the integrated 2.0 hub resume from suspend. But shouldn't the xHCI host controller report that port state? Or do you think it's a host bug as well? > > At least we have the hibernate issue solved though! It seems like we > > just need these three patches (even though the last two didn't help with > > the VIA hub, it could still cause issues on other hosts): > > > > [RFT 2/5] xhci: Don't write zeroed pointers to xHC registers. > > [RFT 4/5] xhci: Restore event ring dequeue pointer on resume. > > [RFT 5/5] xhci: Fix register save/restore order. > > > > Does that sound correct? > > > > I agree with your opinions. So we have to add a XHCI_RESET_ON_RESUME > quirk for VIA host before the suspend operation is finished. I'm a bit confused. Are you saying that the USB 2.0 hub comes back fine (answers to a set address) if we ignore the register restore step for S3 resume and just halt and reset the host controller? Meaning that the VIA host needs your original XHCI_RESET_ON_RESUME quirk patch on top of patch 2? If so, can you refine your patch to only set the reset resume for the specific revisions of VIA hosts that have this issue? I'd like to give VIA the chance to fix this issue in their future chip revisions. Sarah Sharp -- 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
