On Wed, 17 Jul 2002, Duncan Sands wrote: > Hi Dave, it is the same with both UHCIs. I've been looking > at where the port reset (which kills the modem) actually happens. > It is in uhci-hub.c, in the routine uhci_hub_control (case SetPortFeature). > The code is as follows (not my favorite coding style): > > SET_RH_PORTSTAT(USBPORTSC_PR); > mdelay(50); /* USB v1.1 7.1.7.3 */ > c_p_r[wIndex - 1] = 1; > CLR_RH_PORTSTAT(USBPORTSC_PR); > udelay(10);
There is some section in ch. 11 (Hub) of the USB-spec (v1.1 at least) which describes how the hub deals with resetting downstream ports. IIRC ports are free to determine the speed of the attached device either before or after signaling the reset state. If done afterward it would need some time with the buspower still off and IIRC a window in the order of 1msec is granted for the hub to do so. I'm just wondering what might happen if V_bus gets applied only 10usec after the reset has been finished and just collides with the hub trying to determine the device speed - might be worth to increase this delay? > SET_RH_PORTSTAT(USBPORTSC_PE); > mdelay(10); > SET_RH_PORTSTAT(0xa); > OK(0); > #define OK(x) len = (x); break <= Nice place to put break, hey! Wow, that one I really like ;-))) > Do you know which spec this sequence of operations is defined in? Should be all in the usb spec (www.usb.org). Martin ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
