Hi Alan and Sarah, I confirmed that simply calling usb_set_altinterface (which via libusb calls the kernel function usb_set_interface) does correctly clear the toggle bits for USB2 or sequence number for USB3 on an XHCI host controller, even when the alternate interface setting is the same as the previous setting sent to the device. I also agree that if an update is made to usb_reset_endpoint is ideal. That way, Linux would be more consistent with Windows and Darwin. Calling usb_clear_halt will send the control transfer to the device and clear the appropriate toggle/sequence number on the host via the call to usb_reset_endpoint that is embedded within usb_clear_halt. Thanks all, Yuliya On Mon, Oct 15, 2012 at 1:25 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 15 Oct 2012, Sarah Sharp wrote: > >> I double checked, and calling usb_set_interface for the same alternate >> setting that is currently installed will cause the xHCI driver to drop >> and re-add the current endpoints. This should cause the toggle to be >> reset for the endpoints. >> >> I suppose the xHCI driver could do the same thing internally: if >> usb_reset_endpoint() is called with an endpoint that isn't halted, we >> could issue a Configure Endpoint command to drop and re-add the >> endpoint. But we would need to make sure the bandwidth mutex is held, >> and I would have to look at whether it would be safe to add mutex >> locking calls in usb_hcd_reset_endpoint(). > > Probably the best way for xhci-hcd to implement usb_reset_endpoint is > to issue a Configure Endpoint command unconditionally. > > Yes, usb_hcd_reset_endpoint is always supposed to be called in process > context, although this doesn't seem to be documented anywhere. > > 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
