On Mon, 17 Dec 2007, Graeme Gill wrote:

> At least on the system I've been using for testing (RH4 clone, kernel 
> 2.6.9-55.EL),
> all this works pretty well, although the exact semantics of using
> usb_detach_kernel_driver_np() aren't very well documented. I was doing 
> something like:
> 
>       usb_open()
>       usb_set_configuration()
>       for all interfaces {
>               usb_detach_kernel_driver_np(iface)
>               usb_claim_interface(iface)
>       }
> 
> without a problem.
> 
> Reports (from Hal V. Engel) though indicated that this doesn't work
> on other systems. Hal found that the usb_set_configuration() call
> was failing, and that he had to re-arrange things thus to get
> it to work:
> 
>       usb_open()
>       usb_detach_kernel_driver_np(0)
>       usb_set_configuration()
>       for all interfaces {
>               usb_claim_interface(iface)
>       }
> 
> So it seems that the underlying ioctl(IOCTL_USB_SETCONFIG) response
> is different on his system to mine. I also experienced the same issue
> with the Huey on a friends system, and the same solution seemed to
> work. (sorry, I don't have the specifics of these two systems).

That's right.  The semantics of USBDEVFS_DISCONNECT has changed since 
2.6.9.  It now requires that there be no drivers bound to any 
interfaces; thus you have to call usb_detach_kernel_driver_np() first.

There's also an excellent chance you don't need to call
usb_set_configuration() at all.  Your devices have got only one
configuration, right?

> A recent report (from Frederic Crozat) using the above sequence is that
> it too doesn't work on some systems (sorry, again I don't have the
> specifics of the system), and fail at the
> usb_detach_kernel_driver_np(0) call:
> 
>   open("/dev/bus/usb/002/004", O_RDWR)    = 3
>   ioctl(3, USBDEVFS_IOCTL, 0xbf7e7814)    = -1 EINVAL (Invalid argument)
>   ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbf7e7834) = -1 EBUSY (Device or 
> resource busy)

The reason for this isn't clear.  It would help to see the entry for 
this device in Frederic's /proc/bus/usb/devices file.  It also might 
help to look for warnings in the kernel log.

> To round out this summary, I'll attach another (relatively unrelated)
> problem that users of ArgyllCMS are bumping against:
> 
> One version of the Eye-One Pro instrument (rev D),
> <http://www.xrite.com/product_overview.aspx?id=790>
>   has a problem when it comes to closing the USB port.

?  Do you mean closing the USB device _file_?

> On my system if I simply close the port on application
> exit, then any subsequent attempt to use the device
> results in:
> 
> Error - Configuring USB port 'usb:/bus0/dev2 (GretagMacbeth i1 Pro)' to 1 
> failed with -71
> (could not set config 1: Protocol error)
> 
> and only un-plugging and re-plugging the device restores it to operation.
> 
> (This doesn't occur on MSWindows or OS X, or using the Rev A instrument.
>   Gretag changed the devices hardware between Rev A and Rev D, and have
>   used a different micro).

It sounds like you're not getting the same USB data sent on Linux and
on the other operating systems.  Have you tried monitoring the USB
transfers and comparing the low-level data?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to