On Mon, 11 Jan 2010, John Ervin wrote: > Alan, > > > > > > You're using the word "reset" to mean several different things. Can > > you be more explicit? > > > > By reset I mean resetting the USB device chip's cpu to use the new firmware I've > just downloaded using the USB device driver (Cypress, the chip vendor, calls > this process 'reenumeration'). Other people know more about this than I do. Isn't there a specific request you send the device to cause the CPU to reset? > > > > What sort of "simple reset" do you want to do? A USB port reset? And > > in what context do you want to do it? The driver's probe() routine? > > The reset of the USB devices chip's cpu. > No not the USB port, though maybe I should be doing that as well. Is there a > simple call for this? usb_reset_device(). > I was doing this in the open routine, not in probe. You're likely to run into trouble, because the reenumeration will cause the device's descriptors to change and that will cause the kernel to unbind the existing driver. Thus the open call will end up associated with a defunct device instance. Normally firmware is sent while probe() runs and the device's CPU is reset right away. The driver gets unbound and rebound, and the second time through the probe() routine recognizes that the firmware has already been installed. Alan Stern -- 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
