On Fri, Jul 20, 2012 at 3:37 AM, Oliver Neukum <oliver@xxxxxxxxxx> wrote: > > We cannot do this as the device state is specific to a driver. And the driver > must have an interface to be bound to. That is why we use reset_resume() > instead of resume(). resume() means that the device must be brought up > but has retained internal state. reset_resume() tells a driver that the internal > state has been lost. The lost internal state is only visible to device or driver inside, and for user space application, it is still the original device, and both resume() and reset_resume() are no difference if the device is not disconnected. I mean for the firmware things involved, we can cache the firmware for interfaces until the device is disconnected, so interface driver can download firmware during resume path. But as Alan pointed out in another email, the reset may not complete successfully, so the device will be disconnected and enumerate again. For this situation, firmware downloading is not a big problem since it happens in .probe path. But user space application will find the device changed. Thanks, -- Ming Lei -- 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
