On Wed, 16 Jul 2014, Pratyush Anand wrote: > Hummmm..May be this solution is not perfect. Have been reported with > at least one device which failed with this patch too. A print of > link_state for that device(sleep changed to 2ms) shows that for a long > time link was in rxDetect. May be I will try to see with analyzer what > exactly happens with such devices. > > Giving 2nd thought to timeout calculation: Probably we can not > calculate timeout by adding all substates timeout. It would be valid > only when link does not go back in the state machine. For example, it > might happen that host is in polling.active and it did not receive > sufficient number of TS2 in tPollingActiveTimeout and so it moves > backward to polling.LFPS. But next time when state machine advances, > it is able to reach to U0. So the total time may be more than 400 mS > and a successful linkup. Device which failed with this patch worked > with 2000 ms timeout :( Not sure how can we manage timeout. 2 seconds seems like too long to wait. I don't understand why USB-3 links take so long to train. Alan Stern -- 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
