On Wed, 11 May 2011, Marc St-Jean wrote: > On 11-05-11 02:28 PM, Alan Stern wrote: > > On Wed, 11 May 2011, Marc St-Jean wrote: > > > >>> There are a couple of things you could do. The easiest is to unload > >>> the gadget driver and then reload it a second or so later. For > >>> example, if you're using g_ether: > >>> > >>> rmmod g-ether > >>> sleep 1 > >>> modprobe g-ether > >> I'm assuming you mean g_ether.ko? I've tried this already and it didn't > >> appear to help. > > I tried again with a module based build in case I was doing something > wrong, but no luck. > Somehow unplugging or interrupting VBUS causes additional steps to occur > in the host. Have you tried out my suggestion of testing with a linux-based host? That's the best way to tell what's really going on, short of using a bus analyzer. > Here's essentially what I'm doing in my reset script to simulate a > reboot. It works the first time after unplugging but will not force the > host to reestablish IP networking if re-ran. The output of ifconfig and > route all looks fine. > > killall dhcpd > ifconfig usb0 down > > rmmod g-ether > #rmmod arcotg-udc > #rmmod fsl-otg-arc > sleep 5 (tried up to 20) > modprobe fsl-otg-arc > #modprobe arcotg-udc > #modprobe g-ether I assume these '#' characters were added after the fact, because they don't match properly. > iptable --flush > more iptable to reestablish NATing > > ifconfig usb0 up 10.10.0.1 netmask 255.255.255.0 > dhcpd -S > > I also tried building otg supoprt and udc driver as modules with the > above lines uncommented but it made no differences. > > >>> Alternatively, if you can change the source code for the gadget driver > >>> and if your controller driver supports this, you can have the gadget > >>> driver call: > >>> > >>> usb_gadget_disconnect(gadget); > >>> ssleep(1); > >>> usb_gadget_connect(gadget); > >> I'm assuming this is equivalent to the rmmod above? > > More or less. > > I'm very interested in trying the code method as I see that these > functions control the pullups. Earlier this week I found an Oct 29, 2008 > post by you suggesting the D+/- pullup method to force enumeration. > > Are you suggesting this code should be added to the g_ether driver > (ether.c)? > Where should it go, at bind time (i.e. in eth_bind())? Things aren't that simple. Unloading g-ether should cause the UDC driver to call its own disconnect routine (i.e., to remove the D+ pullup). If it doesn't, that's a bug in the UDC driver and it should be fixed. I don't recognize arcotg-udc; is it part of the standard kernel? The only advantage to adding these calls to g-ether is that it means you don't have to go through the rigmarole of unloading and reloading the g_ether.ko module (which could be advantageous if for some reason you don't want to use loadable kernel modules). Functionally the result should be the same either way. Right now there is no correct place in g-ether to put these calls. You would have to figure out a way to add them, possibly triggered by a write to a new sysfs attribute file. IMO, unloading and reloading the module is easier. 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
