On 11-05-11 08:58 PM, Alan Stern wrote:
On Wed, 11 May 2011, Marc St-Jean wrote:
On 11-05-11 02:28 PM, Alan Stern wrote:
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.
No not yet, I will give it a try.
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.
That's right, I was trying to show both the simple and all-in cases I
tried. Should have read as-is now.
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 had checked this before and the support appears to be in place. I've
added debugging and proving this out now.
I don't recognize arcotg-udc; is it part of the standard
kernel?
It's vendor supplied and GPL2'd so I can post it if you'd like. Here's
the pullup function:
/* Change Data+ pullup status
* this func is used by usb_gadget_connect/disconnet
*/
static int fsl_pullup(struct usb_gadget *gadget, int is_on)
{
struct fsl_udc *udc;
udc = container_of(gadget, struct fsl_udc, gadget);
udc->softconnect = (is_on != 0);
if (can_pullup(udc))
fsl_writel((fsl_readl(&dr_regs->usbcmd) | USB_CMD_RUN_STOP),
&dr_regs->usbcmd);
else
fsl_writel((fsl_readl(&dr_regs->usbcmd) & ~USB_CMD_RUN_STOP),
&dr_regs->usbcmd);
return 0;
}
/* defined in gadget.h */
static struct usb_gadget_ops fsl_gadget_ops = {
.get_frame = fsl_get_frame,
.wakeup = fsl_wakeup,
/* .set_selfpowered = fsl_set_selfpowered, */ /* Always selfpowered */
.vbus_session = fsl_vbus_session,
.vbus_draw = fsl_vbus_draw,
.pullup = fsl_pullup,
};
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.
Yes we would prefer to statically link if possible as it simplifies our
upgrade system.
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
I was think of an ioctl but an attribute would make it much easier to
access from scripts, etc.
Marc
--
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
