On Friday 25 January 2008, Alan Stern wrote: > On Thu, 24 Jan 2008, David Brownell wrote: > > > Some of the "EHCI ports reset forever" problems may be explained by > > code paths which wrongly flagged resets as complete. This removes > > two such paths; the ehci_hub_status_data() path should be the only one > > to have an effect, since it was already properly flagged on the other > > path. (Issue noted by Minhyoung Kim <[EMAIL PROTECTED]>.) > > > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > --- > > Worth having some testing on this ... I'm not sure when that test > > got into the hub_status_data() call, there's a chance it's working > > around some other problem. > > It's already in there as of the earliest version in a Git repository > (2.5.early from back in 2002).
Right. I didn't feel like going back to the BK history, but presumably that would help. > You should note that if a disconnect or a connect-status-change is > detected during a reset (possible but unlikely since the reset signal > overrides the levels used for detecting disconnects), the hub driver > exits early -- it does not wait for the reset to complete. So long as it eventually retrieves port status, the reset should complete. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
