On Mon, 9 May 2005, David Brownell wrote: > So it's yet another case where the /sys/.../power/state attributes > facilitate breaking things... :)
I prefer to think of it as a case where the debugging advantages of those attributes have helped turn up a mistake in a driver. :-) > > The code still isn't quite right because the root hub doesn't > > automatically resume. I haven't tried to track down the reason, but maybe > > replacing the schedule_work() call with usb_hcd_resume_root_hub() would > > help. (That replacement should be made in any case.) > > And that might also explain part of why I've never seen this. > Last time I tested this stuff out, there was no such usb_hcd_*() > call .. I suspect adding it changed a few assumptions. No, the usb_hcd_* stuff is completely unrelated to the original problem of that INTR_RD hanging the system. And adding it didn't change any assumptions -- it was a very simple addition of the "what you don't know won't hurt you" sort. (Basically just a new flag plus a routine to set it and some code to make khubd resume the root hub when the flag was set; if a driver ignored the flag then nothing unexpected would happen.) Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
