| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
| |
If libusb_get_max_packet_size() or libusb_get_max_iso_packet_size()
fails to find the endpoint, it leaks the configuration descriptor. Fix
this.
Signed-off-by: John Sheu <sheu@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
| |
It looks like *ifcp should be the same as iface,
so I just use the latter instead of the former.
Closes pull request #13
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
| |
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
| |
If submission fails libusb_ref_device will never get balanced by an unref
on completion, since there will be no completion.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a possible deadlock due to a lock ordering reversal, caught by Coverity:
*** CID 62579: Thread deadlock (ORDER_REVERSAL)
/libusb/io.c: 1451 in libusb_submit_transfer()
1445 r = calculate_timeout(itransfer);
1446 if (r < 0) {
1447 r = LIBUSB_ERROR_OTHER;
1448 goto out;
1449 }
1450
>>> CID 62579: Thread deadlock (ORDER_REVERSAL)
>>> Calling "pthread_mutex_lock" acquires lock "libusb_context.flying_transfers_lock" while holding lock "usbi_transfer.lock" (count: 1 / 4).
1451 usbi_mutex_lock(&ctx->flying_transfers_lock);
1452 r = add_to_flying_list(itransfer);
1453 if (r == LIBUSB_SUCCESS) {
1454 r = usbi_backend->submit_transfer(itransfer);
1455 }
1456 if (r != LIBUSB_SUCCESS) {
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This really is a false positive, but easy enough to silence:
*** CID 62578: Failure to restore non-local value (MISSING_RESTORE)
/libusb/os/linux_udev.c: 64 in linux_udev_start_event_monitor()
58 int r;
59
60 assert(udev_ctx == NULL);
61 udev_ctx = udev_new();
62 if (!udev_ctx) {
63 usbi_err(NULL, "could not create udev context");
>>> CID 62578: Failure to restore non-local value (MISSING_RESTORE)
>>> Value of non-local "udev_ctx" that was verified to be "NULL" is not restored as it was along other paths.
64 return LIBUSB_ERROR_OTHER;
65 }
66
67 udev_monitor = udev_monitor_new_from_netlink(udev_ctx, "udev");
68 if (!udev_monitor) {
69 usbi_err(NULL, "could not initialize udev monitor");
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We scan the list of open devices to find the device-handle based on the fd,
add a check to ensure that we've actually found the handle before continuing.
This fixes the following Coverity warning:
*** CID 62575: Explicit null dereferenced (FORWARD_NULL)
/libusb/os/linux_usbfs.c: 2594 in op_handle_events()
2588 hpriv = _device_handle_priv(handle);
2589 if (hpriv->fd == pollfd->fd)
2590 break;
2591 }
2592
2593 if (pollfd->revents & POLLERR) {
>>> CID 62575: Explicit null dereferenced (FORWARD_NULL)
>>> Dereferencing null pointer "hpriv".
2594 usbi_remove_pollfd(HANDLE_CTX(handle), hpriv->fd);
2595 usbi_handle_disconnect(handle);
2596 /* device will still be marked as attached if hotplug
monitor thread
2597 * hasn't processed remove event yet */
2598 usbi_mutex_static_lock(&linux_hotplug_lock);
2599 if (handle->dev->attached)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no reason to mark init_count as volatile, it is protected by the
linux_hotplug_startstop_lock. Removing the volatile marking fixes the
following Coverity warning:
*** CID 62574: Side effect in assertion (ASSERT_SIDE_EFFECT)
/libusb/os/linux_usbfs.c: 460 in op_exit()
454 return r;
455 }
456
457 static void op_exit(void)
458 {
459 usbi_mutex_static_lock(&linux_hotplug_startstop_lock);
>>> CID 62574: Side effect in assertion (ASSERT_SIDE_EFFECT)
>>> Argument "init_count" of assert() has a side effect because the variable is volatile. The containing function might work differently in a non-debug build.
460 assert(init_count != 0);
461 if (!--init_count) {
462 /* tear down event handler */
463 (void)linux_stop_event_monitor();
464 }
465 usbi_mutex_static_unlock(&linux_hotplug_startstop_lock);
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
| |
* On XP environments, the call to GetSystemMetrics() fails without an explicit reference to user.lib...
which end user applications would also need to do.
Considering that this call was just to differentiate Windows 2003 from 2003 R2, just remove it.
|
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
| |
* ...since Microsoft broke IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX between Windows 7 and Windows 8
* Also improve Windows version detection and reporting
* Closes #10
|
|
|
|
| |
* This can be quite useful for troubleshooting user issues
|
|
|
|
|
|
| |
* libusb has been added to Coverity at https://scan.coverity.com/projects/2180
* Use "// coverity[keyword]" to silence the issues we don't care about
* All other issues from the Windows build have been fixed, apart from the closing of the DLLs.
|
|
|
|
|
|
|
|
|
| |
This implementation makes use of the IOKitWaitQuiet which waits until
all IOKit processing is complete. The performance won't necessarily be
great but it should help codes that have not yet or cannot move to the
libusb hotplug API.
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
|
|
| |
* void function call was returning a value
* introduced in 6d8dfe0aee41a3c7dd862c3de488df3ce452d86e
* also fix whitespaces
|
|
|
|
|
|
|
|
|
|
|
|
| |
The backend was incorrectly calculating the addresses of endpoints
with directions other than kUSBIn and kUSBOut. This primarily affects
devices with multiple control endpoints. This commit should correct
the issue by only setting the direction bit when the direction is
kUSBIn.
Thanks to Jean-Etienne for identifying the issue.
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
|
|
| |
Clean up some code in the darwin backend.
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
|
|
|
|
| |
This commit adds support for bulk streams to the darwin backend. I
have not had a chance to fully test this code as I have no access
to any devices that use this interface.
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
|
|
|
|
|
| |
In the Xcode project, set:
LD_DYLIB_INSTALL_NAME = @rpath
Such that the built dylib's install name uses rpath, which is
generally what one wants.
|
|
|
|
| |
The parameters already match the function declaration; no need to cast.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Being able to allocate bulk-streams is not really useful if the user cannot
specify the stream ids when submitting transfers.
The actual stream id gets added to our private itransfer struct, and a setter +
getter are added to get to it. Unfortunately this is the only way to add
support for stream ids without breaking ABI. So this is another item to fix
when we do break ABI in libusb-2.0.
Bulk streams also use a separate transer type, to allow backends to determine
if a transfer is a bulk stream transfer or an ordinary bulk transfer. This is
added because there is no other reliable way to determine if a transfer is
a stream as the stream_id is part of the private itransfer struct so apps
re-using a transfer may not set it to 0. Adding a separate transfer-type
for this was suggested (and coded) by Nathan Hjelm.
Most users will likely use the new libusb_fill_bulk_stream_transfer()
though, and will never know the difference.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DEVNUM but do have a DEVICE parameter.
These netlink events are now parsed:
>>>>>>>>>>>>>>>>>
add@/devices/platform/brcm-ohci-0.0/usb3/3-2/3-2:1.0
ACTION=add
DEVPATH=/devices/platform/brcm-ohci-0.0/usb3/3-2/3-2:1.0
SUBSYSTEM=usb
SEQNUM=290
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/003/003
PRODUCT=45e/28e/114
TYPE=255/255/255
INTERFACE=255/93/1
<<<<<<<<<<<<<<<<<
Also added a retry when opening the device file to work around a race condition with the kernel
|
|
|
|
| |
* Closes #3
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
I also updated the documentation on the backend get_config_descriptor
function. The documentation incorrectly stated that this function returns
0 on success when it really returns the length of the descriptor.
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
| |
* Make it the same as the one used on the website and elsewhere
|
|
|
|
|
|
|
|
| |
Using an atexit function to cleanup the state could cause weird interactions
with other atexit functions. Ensure the darwin cleanup function is called
last by making it a destructor function instead.
Signed-off-by: Nathan Hjelm <hjelmn@me.com>
|
|
|
|
|
|
|
|
| |
* The driver has to be updated to version 1.0.0.66 (2011-10-25) or later
* Older versions can fail with the following warning:
could not get node connection information for device [..]: [87] The parameter is incorrect.
* Also Remove duplicated "API" string in debug output
* Closes #1
|
|
|
|
|
| |
* add a missing call to libusb_handle_events_completed()
* add a missing argument to libusb_hotplug_deregister_callback()
|
|
|
|
| |
* Has VID:PID 8086:1111
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* Some MinGW platforms may not have FACILITY_SETUPAPI defined
* Issue introduced with 8b46e1c088167eb86b1712765896e2f17d70d148
|
|
|
|
|
| |
* The sessionID value is 64-bit, so print it as such.
* Closes #153
|
|
|
|
|
|
| |
* GetPipeProperties() may fail when the device is unplugged if DeviceVersion is not greater than 320.
* In this case maxPacketSize will be zero and the integer division will throw a EXC_ARITHMETIC signal.
* Closes #136
|
|
|
|
| |
* Closes #117
|
|
|
|
|
|
|
|
| |
* http://msdn.microsoft.com/en-us/library/windows/hardware/ff545011.aspx
states that SetupAPI errors must be be converted before passing it to FormatMessage().
* Use our own implementation of HRESULT_FROM_SETUPAPI to avoid defining a new function call.
* Issue and original fix suggested by Matthias Bolte
* Closes #166
|
|
|
|
| |
* Closes #157
|