On Mon, 21 Feb 2011, Paul Bolle wrote: > On Mon, 2011-02-14 at 22:15 -0500, Alan Stern wrote: > > In general not much can be done about over-current problems, other than > > unplugging the device that's drinking too much current. > > In my case it is apparently generated by that particular (builtin and > UHCI) hub itself (as there are no devices attached to any ports at all). > Does that change anything? No. > > In my > > experience these conditions are almost always very short-lived (a > > fraction of a second), in which case no recovery action is needed. > > > > [...] > > > > Maybe we should delay for 500 ms and then check the port status again. > > It would make sense to log an error message if the over-current status > > persists, otherwise dev_dbg would be fine. > > Nobody stepped in to comment. Perhaps I should try to draft a patch. Go ahead. > Are > you thinking about something that uses the delayed work interface (ie, > the interface now already used for hub->init_work and hub->leds)? No, I'm thinking of msleep(500). Or maybe 100 ms would be enough. 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
