On Linux we often need to read (postive) integers from sysfs. This patch
adds a helper function for this. This is a preparation patch for adding
a libusb_get_device_speed() function to libusb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When an interface is bound to the usbfs driver (iow claimed), the
kernel will unbind it, and then after the reset do a device_attach
on the interface, which will bind the default in kernel driver to
the interface.
So if an app has detached the in kernel driver, and claimed the
interface and then does a libusb_reset_device. Things end up with
the interface no longer being bound to the usbfs driver (so no longer
claimed) and instead it is bound to the in kernel driver (iow the in
kernel driver is re-attached).
We can stop this from happening by releasing all claimed interfaces
before the reset, as the kernel will not do the device attach after
reset, if no driver was bound to the interface before the reset.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
claimed_interfaces is a long and thus its size differs on 32
versus 64 bits, this patch uses USB_MAXINTERFACES instead of
sizeof(claimed_interfaces) on interface number range checks
for consistent behavior independent of the arch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Compiling with gcc-4.6 results in the following warnings:
os/linux_usbfs.c: In function 'op_get_configuration':
os/linux_usbfs.c:1144:6: warning: variable 'r' set but not used ...
os/linux_usbfs.c: In function 'op_handle_events':
os/linux_usbfs.c:2091:40: warning: 'status' may be used uninitialized ...
os/linux_usbfs.c:2044:6: note: 'status' was declared here
dpfp.c: In function 'save_to_file':
dpfp.c:228:9: warning: variable 'ignore' set but not used ...
dpfp_threaded.c: In function 'save_to_file':
dpfp_threaded.c:257:9: warning: variable 'ignore' set but not used ...
This patch fixes these. (The second comes from handle_control_completion()
which gcc seems to inline into op_handle_events().)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[stuge: Add fixes for dpfp examples and update source references]
Change the way libusb chooses between using sysfs and usbfs for information
about the attached devies. Using the old method, a race condition could
occur if a device was unplugged just before (or during) the call to
libusb_get_device_list(), corrupting the internal sysfs_can_relate_devices
and sysfs_has_descriptors variables and preventing libusb_get_device_list()
from working in future calls.
The old method was based on the assumption that if certain sysfs files
(eg: busnum) could not be opened, that indicated an inadequacy of sysfs
(ie: the running kernel's sysfs version did not contain those files),
when in reality those files couldn't be opened because the device had
been unplugged.
The new method checks the adequacy of sysfs during libusb_init()
(op_init()) and if a sysfs file cannot be opened, it is now assumed that
it is because the device has been unplugged, not because sysfs is
inadequate.
Signed-off-by: Alan Ott <alan@signal11.us>
[stuge: Include closedir() bugfix posted in ticket by Arne Laansoo]
[stuge: Remove dead code in sysfs_scan_device() found by Hans de Goede]
In parse_interface() an unexpected descriptor would be parsed without
validating the descriptor's length. It is possible for size to be 0 at
this point, which means that the parsing would read past the end of the
source buffer. Fix#83 by checking the length of the remaining buffer
before parsing.
Any in-flight transfers should properly invalidate their references
to device handles that are being closed. Additionally, they should be
removed from the transfer-in-flight list. This is done with the events
lock held to protect against another thread processing the same transfer.
The events lock is initialized as a recursive mutex, because the device
close code might itself be called while an event is being handled.
Fixes#82.
[stuge: Trivial rework to reduce indenting]
The flags are used to indicate if a cancellation has started, and if
a cancellation has failed because the device is no longer available.
References #82.
This is necessary for the device close path which needs to attain the
events lock, but which might itself be called while handling an event.
The events lock is necessary to properly clean up transfers which might
still be pointing to the device. References #82.
* Current Nec/Renesas USB 3.0 driver lists root hubs under
the "NUSB3" PnP Symbolic Name
* This results in root hubs not being acknowledged during enum
* Microsoft has changed the service name for 3.0 hubs
* not identifying 3.0 hubs could result in a "device only
detected in late pass - ignoring" message
* issue reported by Dave Camarillo