On Thu, Mar 22, 2012 at 11:35:28AM -0700, Sarah Sharp wrote: > > 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. Hello, Not to sidetrack the discussion here, I have been trying to poke at the same issue (a VIA hub can't set the address after a few disconnect/connect cycles). If you guys have any hacked up patches, I wouldn't mind giving them a try. Otherwise I was going to figure out a way to just reset the port and try again, if possible. Thanks, Don > > > > 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 -- 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
