On Thu, Aug 23, 2012 at 1:55 AM, David Grant wrote:
> I don't understand why that would be the case. libusb + libusbK seems like
> the perfect solution for us especially when we consider the fact that we are
> already using libusb in the Linux (x86 + ARM) environments with great
> success. It just
On 2012.08.22 18:55, David Grant wrote:
> It just seems like the driver swapping is the main
> issue we need to resolve.
Well, if you want to contribute a driver swapping/removal patch to
libwdi, I'll be happy to review it.
Regards,
/Pete
---
On 2012.08.22 11:21, Hans de Goede wrote:
> I would prefer to stick with the __u32, as that is what is in the kernels
> *userspace* headers
It's 2012, C99 + stdint.h have been around for more than decade [1],
and, unlike what may be the case for kernel developers who may worry
about C89 compatib
Well, that was really a one in a billion issue (or more realistically a
one in a million, as I doubt one actually gets nanosec level timer
resolution during code execution, even on the fastest machine).
I have now pushed Peter's patch, amended to fix the other location where
we were using a > i
On Tue, Aug 21, 2012 at 10:14 PM, Xiaofan Chen wrote:
> On Wed, Aug 22, 2012 at 8:04 AM, David Grant wrote:
> > Thanks for the detailed response Pete.
> >
> > So the big missing feature seems to be how to remove libusbK.sys and
> replace
> > it with the original driver without having to embed th
On Wed, 22 Aug 2012, Hans de Goede wrote:
> >> + if ((dc.flags & USBDEVFS_DISCONNECT_CLAIM_IF_DRIVER) &&
> >> + strncmp(dc.driver, intf->dev.driver->name,
> >> + sizeof(dc.driver)) != 0)
> >> + return -EBUSY;
> >> +
> >> +
Hi,
On 08/22/2012 05:05 PM, Alan Stern wrote:
> On Wed, 22 Aug 2012, Hans de Goede wrote:
>
>> Apps which deal with devices which also have a kernel driver, need to do
>> the following:
>> 1) Check which driver is attached, so as to not detach the wrong driver
>> (ie detaching usbfs while anot
On Wed, 22 Aug 2012, Hans de Goede wrote:
> Apps which deal with devices which also have a kernel driver, need to do
> the following:
> 1) Check which driver is attached, so as to not detach the wrong driver
>(ie detaching usbfs while another instance of the app is using the device)
> 2) Detac
On Mon, Aug 20, 2012 at 8:32 AM, Pete Batard wrote:
> Hopefully will help getting more testing before next release.
>
> I'm closing #11 and #12 as a result (isoc support will be dealt elsewhere).
>
> I also pushed the patch provided for #41
> (https://github.com/libusbx/libusbx/pull/41).
>
The te
Hi,
Thanks for the review!
On 08/22/2012 02:04 PM, Oliver Neukum wrote:
> On Wednesday 22 August 2012 13:42:47 Hans de Goede wrote:
>> Apps which deal with devices which also have a kernel driver, need to do
>> the following:
>> 1) Check which driver is attached, so as to not detach the wrong dri
On Wednesday 22 August 2012 13:42:47 Hans de Goede wrote:
> Apps which deal with devices which also have a kernel driver, need to do
> the following:
> 1) Check which driver is attached, so as to not detach the wrong driver
>(ie detaching usbfs while another instance of the app is using the dev
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
(ie detaching usbfs while another instance of the app is using the device)
2) Detach the kernel driver
3) Claim the interface
Where mov
As discussed before apps which do driver-check, driver-detach, claim currently
all are more or less racy. This patchset
1) Introduces a new libusb function which allows apps to do this kind of thing
in a single call.
2) Makes use of a new ioctl to do this in a race free matter, on systems where
thi
Signed-off-by: Hans de Goede
---
libusb/os/linux_usbfs.c | 28
libusb/os/linux_usbfs.h | 10 ++
2 files changed, 38 insertions(+)
diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index b6194ce..9cadca0 100644
--- a/libusb/os/linux_usbfs.c
+++ b/
I've been seeing these intermittent failures to reclaim an interface after
a device reset. After much debugging and inserting sleeps in strategic
places to make the race window larger I've found the following race:
1) A user is running some software using libusbx which will automatically
detect,
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
(ie detaching usbfs while another instance of the app is using the device)
2) Detach the kernel driver
3) Claim the interface
Where mov
Currently applications for devices which only are accessed from userspace
can use claim / release interface to make sure they don't get in each others
way. The same however does not work for applications which first need to detach
a "native" / in kernel driver, as this detach will not only detach n
There were a few (new) usbdevfs capabilities which libusbx could not
discover in any other way then checking the kernel version. There are 3
problems with this:
1) It is just not very pretty
2) Given the tendency of enterprise distros to backport stuff it is not
reliable
3) Some of these feature
With the latest kernels it is no longer needed to always split large bulk
transfers into multiple urbs. This patch takes advantage of this by not
splitting when not necessary. Note that the non-split code path is in essence
using the old split code path with an urb count which is always 1.
This le
Here are my recent Linux patches, with the review comments taken into account,
changes in v2:
1) Avoid a divide by 0 on 0 length bulk packets
2) Improve the various commit messages
Regards,
Hans
--
Live Security Virtual
Hi,
Thanks for the reviews!
On 08/22/2012 01:42 AM, Pete Batard wrote:
> Thanks for these patches. Just a couple points so far:
>
> On 2012.08.20 22:10, Hans de Goede wrote:
>> +__u32 caps;
>
> Are stdint.h and the kernel expected to be potentially out of sync with
> regards to what constitut
Hi,
On 08/22/2012 11:14 AM, Xiaofan Chen wrote:
> On Tue, Aug 21, 2012 at 5:10 AM, Hans de Goede wrote:
>> + /*
>> +* Older versions of usbfs place a 16kb limit on bulk URBs. We work
>> +* around this by splitting large transfers into 16k blocks, and then
>> +* submi
Hello Peter,
On 22.08.2012 10:39, Peter Stuge wrote:
> Here's a patch to fix that bug, but I'm not sure if it is enough to
> completely solve the problem.
thank you for the patch.
I hope that it will solve it.
=
Regards
Sebastian
=
On Tue, Aug 21, 2012 at 5:10 AM, Hans de Goede wrote:
> + /*
> +* Older versions of usbfs place a 16kb limit on bulk URBs. We work
> +* around this by splitting large transfers into 16k blocks, and then
> +* submit all urbs at once. it would be simpler to submit one u
On Tue, Aug 21, 2012 at 5:12 PM, Hans de Goede wrote:
> Signed-off-by: Hans de Goede
> ---
> libusb/core.c | 4
> libusb/os/linux_usbfs.c | 6 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/libusb/core.c b/libusb/core.c
> index 7c2f4d7..4c513f7 100644
> --- a/libusb/c
sebastiank wrote:
> libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 22,
> it_value = 259823:10)
Here's a patch to fix that bug, but I'm not sure if it is enough to
completely solve the problem.
//Peter
>From 3b821d0a709c6b5b3094a763bb04e48ed0447050 Mon Sep 17 00
On 16.08.2012 22:46, Pete Batard wrote:
> If you're using the version of libusbx with the latest patches, we
> will get the needed inisght about the cause for the error.
I'm using the latest git-mainline version of libusbx on all machines,
with the extra debugging output you advised me to include.
27 matches
Mail list logo
