Hi Kevin,
On Sat, June 30, 2012 1:48 pm, Kevin Cernekee wrote:
> 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.
>
The usb_ep_enable is usally called after the config_ep_by_speed is setting
the endpoint descriptor. For example the gether_connect is called after
config_ep_by speed was called. For this particular case in eth_stop, it
seems that if netif_carrier_ok(net) is true then we just disable and
reenable the endpoints to get rid of active transfers. Maybe instead need
to use ep_dequeue ?? Otherwise need to add a call to ep_config_sp_by_speed
also here (or save desc before disabling it)
Thanks,
Ido
--
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
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
