This is a quirk for your TI host controller because it doesn't properlygive a port status event for the link status change to compliance mode,correct?

First, you need to add that background to your patch description, anddescribe what triggers this behavior and how frequently it can occur.

Second, you need to make a separate xHCI quirk for your host controller,set it based on the PCI vendor and device ID in xhci-pci.c, and only armthe timer if the quirk is set. We don't need this timer for any otherhost controllers, so it should run only for your host.

If you need an example, look through the xHCI driver forXHCI_EP_LIMIT_QUIRK.

Your patch is line wrapped and can't be applied. Please resend with amail client that won't mangle your patches. I personally use mutt, butyou can take a look at Documentation/email-clients.txt for othersuggestions.

Um, what happens if the timer fires while the xHCI host is in PCI D3because it has been auto-suspended? All the registers read as0xfffffff. You should make sure to stop and restart the timer when thethe host is suspended.

Instead of doing the warm reset here, you need to let the USB corehandle it. Here, you should kick khubd for the USB 3.0 roothub bycalling usb_hcd_poll_rh_status(). Look atxhci-ring.c:handle_port_status() for an example.

Then in the xhci-hub.c code that checks for port changes, you shouldfake a link status change. The USB core will notice the status changeand see the port's link status of compliance. Then the USB core willtake care of issuing the warm reset and doing a proper job of timing it.

How often do you really need this timer to run? Do you really want towake your CPU out of deep C states every two seconds? Is there any wayyou can narrow the scope of when the timer runs so that it doesn't runthat often, or increase this timeout to something like 10 seconds?