| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
To ensure that it is stopped before we continue (and if later libusb
gets re-initialized start another thread).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
An error of LIBUSB_ERROR_PIPE simply means the device has no BOS, so don't
log an error to the console for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Some older versions of udev do not automatically set the udev
monitor fd to non-blocking mode. This patch ensures that this is
always set.
HdG: Get flags then or in O_NONBLOCK and set them, rather then setting flags
to only O_NONBLOCK.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
This patch adds the much requested libusb_strerror() function, taking into
account all issues people raised wrt previous attempts.
Criteria / Decisions underlying this implementation:
- Must support translated messages
- Must not use gettext as that does not work well in combination with Windows
(when building with Visual C, or for Windows CE)
- API compatible with FreeBSD and various patched libusb-s floating around
- KISS:
- Do not add any (other) library dependencies
- Do not try to deal with message encodings (iconv), simply always return UTF-8
making encoding the problem of the application using libusb_strerror.
- Defaults to English, so apps which don't want translated messages,
don't need to do anything special
- Defaults to English (with pure ASCII messages), so apps which don't
call libusb_setlocale() don't need to worry about encoding
|
|
Darwin device cache
|
|
configuration is not found
|
|
|
|
This patch attempts to avoid enumerating devices multiple times by
keeping a cache of device information (IOUSBDeviceInterface pointers,
device descriptors, etc) between calls to libusb_init(). This should
avoid two potential problems:
1) Devices that respond slowly to DeviceRequest. These devices can
take multiple seconds to respond and they usually respond with
a failure (on older versions of OSX at least). By keeping track
of these devices the penalty for enumerating them will be paid
only once.
2) Repeated enumeration of the same device may cause
IOCreatePlugInInterfaceForService() to fail. The root cause of
this problem is not well understood but might be a leak in
IOUSBFamily.
To clean up the cached device information an atexit() function is
used.
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Copied with the author's permission under LGPL-2.1 from
usb-benchmark-project/host/benchmark.c in
git://git.gnumonks.org/sam3u-tests.git commit
74959f7ee88f1597286cd435f312a8ff52c56b7e
http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=sam3u-tests.git;a=blob;f=usb-benchmark-project/host/benchmark.c;h=74959f7ee88f1597286cd435f312a8ff52c56b7e
An Atmel SAM3U test firmware is also available in the above repository.
Conflicts:
.gitignore
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Based on earlier work done on this by Maya Erez <merez@codeaurora.org>,
Nathan Hjelm <hjelmn@me.com> and Pete Batard <pete@akeo.ie>.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Based on earlier work done on this by Maya Erez <merez@codeaurora.org>,
Nathan Hjelm <hjelmn@me.com> and Pete Batard <pete@akeo.ie>.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Apps which were written before hotplug support, may listen for hotplug events
on their own and call libusb_get_device_list on device addition.
In this case libusb_get_device_list will likely return a list without the new
device in there, as the hotplug event thread will still be busy enumerating
the device, which may take a while, or may not even have seen the event yet.
To avoid this add a new hotplug_poll backend function and make
libusb_get_device_list call a this before copying ctx->usb_devs to the user.
In this function the backend should ensure any pending hotplug events are
fully processed before returning.
This patch implements hotplug_poll for linux, it should probably be also
implemented for darwin.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
I could not find if libudev is completely threadsafe anywhere, so rework
the lock handling to serialize all libudev accesses. This is a preparation
patch for adding hotplug_poll support, see the next patch in this series.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
A block of AlternateSettings for a certain InterfaceNumber does not necessarily
start with AlternateSetting 0, so check Interface Descriptors belong to
each other by using InterfaceNumber, as specified in the spec.
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>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
wince_get_active_config_descriptor() retrieves configuration descriptors
as raw bytes, in bus-endian order. Therefore, host_endian should be set
to 0 (as in wince_get_config_descriptor()).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The get_device_descriptor backend call done from descriptor.c was passing
in an uninitialized host_endian value. Likewise for the windows backend,
host_endian was not being set from get_[active_]config_descriptor.
Since the 2 problem cases are for different backend calls, we were never using
an uninitialized host_endian, still lets set it everywhere for safety,
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Our core get_config_descriptor_by_value is not exactly pretty nor efficient,
allow the backends to provide something better.
Note that the callback signature differs from get_config_descriptor in that
backend owned memory gets returned. This saves a needless malloc + memcpy +
free. If this turns out to be a problem for some backends we can always
change things to work like get_config_descriptor.
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>
|
|
For some reason the first get config call to determine the total-length
was only reading 8 of the 9 bytes of a full config-desc-header, which
is weird. The Linux kernel reads the full 9 on the first call, so lets
do that in libusb too. Note that for backends which cache the config this
does not matter.
Also check that we've actually gotten back a full header, before parsing it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Since commit 5e479f1821d3294fb1cc70c5867c69eca2551de7:
"Core: Avoid short read failures on broken descriptors"
usbi_os_backend.get_[active_]config_descriptor no longer return on error
(under Linux) when returning less bytes then requested. But
libusb_get_[active_]config_descriptor still not only requests wTotalLength
bytes, but also blindly assumes that on success it has gotten wTotalLength
bytes.
This patch fixes this, it changes all usbi_os_backend.get_*config_descriptor
implementations to return the actual length on success and uses this value as
the descriptor size in parse_configuration().
Note that the linux and wince backends were already returning the actual
length and thus are not touched.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
In usbfs wTotalLength can be trusted, in the sense that the kernel simple
has holes in the descriptors file when a device returns a smaller config
descriptor then advertised.
In sysfs this is not the case, sysfs descriptors only contain descriptors
actually returned by the device, with no holes. The kernel does validate
the bLength field of all the descriptors and removes any invalid ones.
So with sysfs we cannot rely on wTotalLength, since we can trust bLength,
this patch searches forward for a descriptor with type of LIBUSB_DT_CONFIG
to find the next config on sysfs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
We have an implementation of get_configuration with usbfs, so lets use it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Use cached config descriptors instead of doing tons file io, because:
- Less fileio is more
- Less code is more, diffstat for this patch:
1 file changed, 128 insertions(+), 307 deletions(-)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
We rely on the kernel version for determining capabilities, except for
sysfs_can_relate_devices. This changes sysfs_can_relate_devices over to
a kernel version check to.
This makes things more consistent, removes a whole bunch of code, and since
it stops us from needlessly banging sysfs, it reduces the avarage run time for
the stress test on my system from 21.8 to 16.7 seconds.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
With the refactoring of the Linux descriptors handling, we only want to use
sysfs descriptors if they have the complete config descriptors (versus just
the active config descriptor), which is the case since Linux 2.6.26.
This means that we will fallback to using the usbfs descriptors for the device
descriptor on Linux 2.6.23 - 2.6.25, which only have the active config
descriptor. This will cause a tiny performance penalty, but only on these
3 kernel versions (which are not used in any still supported Linux distros),
and then only on library init since we now cache everything.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
In usbfs the config descriptors are config.wTotalLength bytes apart, but the
device may actually return a shorter descriptor then advertised, in this
case the kernel will simply skip over any bytes read which the device did
not actually return. Note the kernel will *not* return 0 data, it will simply
leave the memory passed in to the read call as is.
Therefor this patch clears the buffer before calling read, to ensure that
the non existing parts of the descriptors are always properly zero-ed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Now that the core caches device-descriptors, we end up opening each
usbfs-node or sysfs-descriptors file once on libusb_init anyways.
So we might as well do this on device-init, rather then waiting for the
core to call op_get_device_descriptor. This allows us to simplify the
code in various places.
While we've it open, read the entire file rather then only reading the
device-descriptor. This is practically free, since most of the cost is in
the opening of the file, not in reading it.
Running the stress test, which does 10000 libusb_init calls, takes 21.8 seconds
on avarage on my idle system with 17 usb devices both before and after this
patch, showing that the cost of also reading the config descriptors while
we've the file open is truely neglible.
Note that this patch does not yet use the cached config descriptors, this is
done by a later patch in this series.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The memory gets calloc-ed, so there no need to clear it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
-in 2 cases the passed in host_endian was not being set
-get_config_descriptor was wrongly calling seek_to_next_config with
host_endian set to 1, but the only case where host_endian is 1 is when
reading the device-desc from usbfs, even in usbfs the config descriptors
are in raw format
Note that the 2nd change partly reverts commit
7f2e9f0776386997d2b4c4c47598ab88e3caeb7a
"Linux: Fix usbfs/sysfs config descriptor handling on big-endian"
Which commit msg says: "checked against Documentation/usb/proc_usb_info.txt"
Well guess what, I checked the actual drivers/usb/core/devio.c code
and Documentation/usb/proc_usb_info.txt is *wrong*. I'll send a patch to
update it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
While at it also simplify the path printing in listdevs
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
This new function replaces the now deprecated libusb_get_port_path function,
as that is the only function operating on a libusb_device which also takes
a libusb_context, which is rather inconsistent.
Note we will keep libusb_get_port_path around in the 1.0.x for the forseeable
future for ABI compatibility reasons, but it should not be used in any new
code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
It took me quite a while to debug this, here is a step by step for the race
which I believe is happening in some cases:
1) app calls libusb_submit_transfer
2) libusb_submit_transfer locks itransfer->lock
3) libusb_submit_transfer adds the transfer to the flying list
4) *thread switch*
5) other thread notices POLL_ERR on device fd, calls usbi_handle_disconnect
6) usbi_handle_disconnect find the transfer which is in progress of being
submitted in the flying list
7) usbi_handle_disconnect calls usbi_backend->clear_transfer_priv on the
transfer, this blocks waiting on itransfer->lock
8) *thread switch*
9) libusb_submit_transfer actually tries to submit the transfer now,
calls usbi_backend->submit_transfer, which fails with -ENODEV
10) libusb_submit_transfer *removes* the transfer from the flying list,
unlocks itransfer->lock and returns an error to its caller
11) the caller frees the transfer, meaning the to_cancel pointer in
usbi_handle_disconnect now points to free-ed memory, for extra mayhem
12) *thread switch*
13) usbi_handle_disconnect calls usbi_handle_transfer_completion
14) usbi_handle_transfer_completion tries to remove the transfer from
the flying list *for the 2nd time*
But the first call done from libusb_submit_transfer has already done
this. libusb's list_del looks like this:
static inline void list_del(struct list_head *entry)
{
entry->next->prev = entry->prev;
entry->prev->next = entry->next;
entry->next = entry->prev = NULL;
}
So the first call sets it next and prev to NULL, and then the 2nd call
tries to deref next -> BOOM
For an example backtrace caused by this, see:
https://bugs.freedesktop.org/show_bug.cgi?id=55619#c7
This patch fixes this by letting libusb_submit keep the flying transfers list
locked during submission, so the submission flow changes from:
1) lock flying transfers
add to flying transfers
unlock
2) submit
3) on submission error:
lock flying transfers
remove from flying transfers
unlock
to:
1) lock flying transfers
2) add to flying transfers
3) submit
4) on submission error:
remove from flying transfers
5) unlock
This means that the os backends submit handler now gets called with the
flying transfers lock held! I've looked at all the backends and this should
not be a problem. Only the windows and win-ce backends care about the
flying transfers list at all, and then only in their handle_events handler.
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>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
An app can hold a reference to just a leave device, if then an entire
hub goes away, all removed devices will get there final unref, except for
the one ref-ed by the app. If the app then tries to use parent_dev in anyway
after this, we've a use-after-free bug. This fixes this.
Also remove the lets re-enumerate fix for this from libusb_get_port_path,
I'm not sure what the exact idea behind this fix was, but after this patch
it is no longer needed, and this patch also fixes usage of for example
libusb_get_parent().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
