On Mon, 24 Apr 2006, usb usb wrote: > From a previous post, I came to understand that when > the reset_device fails and returns ENODEV, USB core > re-registers the failed device and reloads my driver.
Well, your driver is already loaded so it doesn't need to be re-loaded. It does get re-probed. > Shouldn't it pick the failed device before moving onto > the next one? It didn't - that's what I meant when I > said it ignored ENODEV.. Is that the right behavior? It is right. When the reset fails, the core adds a request to re-register the device onto a queue. The requests to register the other devices are already on the queue, so they get acted on first. > If I want to reset a device, when I'm no longer in > probe, how do I do a reprobe? I suppose I'm not > allowed to call probe() directly from the driver - > right? Sure you are. But unless you call it under exactly the same conditions as the USB core would, you're liable to run into trouble. Anyway, why do you need to re-probe after a reset? If the reset succeeds then you already know your driver can manage the device. At most you will have to re-initialize the device, but you won't need to re-probe anything. And if the reset fails, then the USB core will automatically unregister and re-register the device, calling your probe routine as part of the process. Again, you won't need to call it yourself. Alan Stern ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
