On Thu, Sep 11, 2014 at 6:13 PM, Xiaofan Chen <[email protected]> wrote: > On Thu, Sep 11, 2014 at 4:15 PM, Paul Fertser <[email protected]> wrote: >> On Thu, Sep 11, 2014 at 04:01:33PM +0800, Xiaofan Chen wrote: >>> 1738 /* usb_set_configuration required under win32 */ >>> 1739 struct jtag_libusb_device *udev = jtag_libusb_get_device(devh); >>> +++ #if IS_WIN32 == 1 >>> 1740 jtag_libusb_set_configuration(devh, 0); >>> +++ #endif >>> 1741 jtag_libusb_claim_interface(devh, 0); >> >> But what if libusbK driver will be made to work exactly like Linux's >> generic usb code one day? Shouldn't it be possible to express the idea >> "set the configuration if needed, but do not reset the device!" in >> libusb-1.0 API in an OS-agnostic way? > > Actually that is the way currently in libusb-1.0 implementation > tries to do, maybe with the exception of Windows (and probably NetBSD as well > but there is no developer for NetBSD anyway, I tried the OpenBSD > code under NetBSD and it worked and that was why it was added). > > I will ask in the libusb mailing list about the Windows implementation. > From the code, it does seem to generate I/O and may cause problem. > > https://github.com/libusb/libusb/blob/master/libusb/os/windows_usb.c > > * from http://msdn.microsoft.com/en-us/library/ms793522.aspx: "The port driver > * does not currently expose a service that allows higher-level drivers to set > * the configuration." > */ > static int windows_set_configuration(struct libusb_device_handle > *dev_handle, int config) > { > struct windows_device_priv *priv = _device_priv(dev_handle->dev); > int r = LIBUSB_SUCCESS; > if (config >= USB_MAXCONFIG) > return LIBUSB_ERROR_INVALID_PARAM; > r = libusb_control_transfer(dev_handle, LIBUSB_ENDPOINT_OUT | > LIBUSB_REQUEST_TYPE_STANDARD | LIBUSB_RECIPIENT_DEVICE, > LIBUSB_REQUEST_SET_CONFIGURATION, (uint16_t)config, > 0, NULL, 0, 1000); > if (r == LIBUSB_SUCCESS) { > priv->active_config = (uint8_t)config; > } > return r; > } >
Hmm, I am not correct here. In the Linux/Windows/Darwin backend, set_configuration will use a control transfer and generate I/O. They are the same in this aspect. It is the application which needs to take care of the caveats mentioned in the libusb API documentation. http://libusb.sourceforge.net/api-1.0/caveats.html#configsel So I think the fix by Paul in Gerrit is correct for libusb-1.0 API. http://openocd.zylin.com/#/c/2288/ Still it does not fix the LPC Link-2 problem because there is another reset code which will actually reset the device (not under Windows) and that will cause another set_configuration by the kernel driver (not by libusb). So if that section is in, there is no way to fix the issue since the set_configuration is done by the kernel driver after the reset and not libusb. I tend to believe that section is not needed (only by trial and error to fix older J-Link FW and libusb-0.1 problem) now. -- Xiaofan ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
