Hi,
I am confused as to whether the UDC driver should be clearing ep->desc
in the usb_ep struct.
Commit f9c56cdd3905c96c600456203637bd7ec8ec6383 (usb: gadget: Clear
usb_endpoint_descriptor inside the struct usb_ep on disable) indicates
that f_serial will have problems if the UDC driver does not clear
ep->desc.
But I also see code in u_ether.c:eth_stop() which seems to assume the opposite:
usb_ep_disable(link->in_ep);
usb_ep_disable(link->out_ep);
if (netif_carrier_ok(net)) {
DBG(dev, "host still using in/out endpoints\n");
usb_ep_enable(link->in_ep);
usb_ep_enable(link->out_ep);
}
The helper functions are:
static inline int usb_ep_disable(struct usb_ep *ep)
{
return ep->ops->disable(ep);
}
static inline int usb_ep_enable(struct usb_ep *ep)
{
return ep->ops->enable(ep, ep->desc);
}
eth_stop() runs on "ifconfig usb0 down".
If my UDC driver clears ep->desc on disable, the subsequent
usb_ep_enable() passes in a NULL endpoint descriptor; the call fails
and this causes major trouble when I try to re-enable the usb0
interface (ifconfig usb0 up). rx_fill() winds up trying to queue
transactions on a disabled endpoint.
Looking at the dummy_hcd driver for reference, I see that it clears
its own private ep->desc (in struct dummy_ep) but doesn't touch the
pointer in struct usb_ep. Other UDC drivers now behave differently
due to the commit referenced above.
Is anyone able to shed any light on this?
Thanks.
--
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
