On Mon, Oct 03, 2005 at 04:44:31PM -0400, Alan Stern wrote:
> On Mon, 3 Oct 2005, Christopher Li wrote:
>
> There is a different way to do it, using sysfs (not usbfs). The "bind"
> and "unbind" attributes are still very new, not yet in many distributions.
>
OK, I will check it out. I don't thi
On Mon, 3 Oct 2005, Christopher Li wrote:
> I did that already, namely using the disconnect ioctl.
> There is a catch as well, that ioctl can't pass the 32 to 64 compat
> layer, so it will not work on 64 bit linux host when the app is 32 bit.
>
> I try to fix that in my local kernel, and I realiz
I did that already, namely using the disconnect ioctl.
There is a catch as well, that ioctl can't pass the 32 to 64 compat
layer, so it will not work on 64 bit linux host when the app is 32 bit.
I try to fix that in my local kernel, and I realize that there is
a million choice to abuse the USBDEVF
On Mon, 3 Oct 2005, Christopher Li wrote:
> Yes, we still need a device level locking protecting. For the user process
> and kernel driver as well.
>
> The set interface is a good example that interface don't exist as a stand
> alone
> entity. Similar things with reset devices.
>
> So until t
On Mon, Oct 03, 2005 at 10:32:19AM -0400, Alan Stern wrote:
> On Sat, 1 Oct 2005, Christopher Li wrote:
>
> It's not a matter of interfering. The problem is that whenever anyone
> does a Set-Configuration, _all_ the current interfaces go away and new
> ones are created. Hence the drivers curre
On Sat, 1 Oct 2005, Christopher Li wrote:
> Hi,
>
> I notices in the recent kernel that set config from usbdevfs
> can fail with -EBUSY.
>
> /* Don't touch the device if any interfaces are claimed.
>* It could interfere with other drivers' operations, and if
>* an interface
Hi,
I notices in the recent kernel that set config from usbdevfs
can fail with -EBUSY.
/* Don't touch the device if any interfaces are claimed.
* It could interfere with other drivers' operations, and if
* an interface is claimed by usbfs it could easily deadlock.