On 08:09 Mon 20 Jun , Oliver Neukum wrote: > Am Montag, 20. Juni 2011, 01:18:09 schrieb matt mooney: > > Hi, > > > > This pertains to usbip, but it is really a general usb question. > > > > So the userspace utility writes to an attribute to identify the device to be > > unbound and allow the driver to change its interal state; then, (in what I > > believe to be a hack) the utility writes to an attribute of the device in > > question to get the usbcore to reprobe the device and issue a disconnect. > > The driver is disconected as soon as you write to "unbind" > > > I noticed that writing to the usbip driver's unbind attribute leaves the device > > unbound, which is obviously not a good thing. > > This is absolutely necessary to guarantee user space that it may > speak to a device through usbfs without any interference by a driver. > In addition we may want to kick drivers off a device while they are not > needed. > > > So how should this be properly handled? > > It is quite properly handled. Okay, let me clarify to make sure I understand. The userspace utility should write to unbind, which it is currently not doing, and should also continue writing to an attribute of the device, which is to be unbound from the driver, in order to initiate a reprobe? That is: (1) read some attribute of the device and save it (in this case bConfigurationValue) (2) write to the necessary attribute of the driver and then to unbind (3) write the attribute read in (1) back to the device, which is now unbound and without a driver, to initiate the reprobe. Thanks, matt > Regards > Oliver > -- > - - - > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) > Maxfeldstra?e 5 > 90409 N?rnberg > Germany > - - - > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
