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.
drivers/usb/host/ehci-hub.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- g26.orig/drivers/usb/host/ehci-hub.c 2008-01-09 01:29:22.000000000
-0800
+++ g26/drivers/usb/host/ehci-hub.c 2008-01-09 01:46:12.000000000 -0800
@@ -393,10 +393,8 @@ static int check_reset_complete (
u32 __iomem *status_reg,
int port_status
) {
- if (!(port_status & PORT_CONNECT)) {
- ehci->reset_done [index] = 0;
+ if (!(port_status & PORT_CONNECT))
return port_status;
- }
/* if reset finished and it's still not enabled -- handoff */
if (!(port_status & PORT_PE)) {
@@ -475,8 +473,6 @@ ehci_hub_status_data (struct usb_hcd *hc
* controller by the user.
*/
- if (!(temp & PORT_CONNECT))
- ehci->reset_done [i] = 0;
if ((temp & mask) != 0
|| ((temp & PORT_RESUME) != 0
&& time_after_eq(jiffies,
-
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