On Thursday 19 July 2012 18:58:38 Ming Lei wrote: > On Thu, Jul 19, 2012 at 5:33 PM, Oliver Neukum <oneukum@xxxxxxx> wrote: > > Yes. That's how reset_resume() works. > > If reset_resume flag is set, usbcore will try to reset the device first > during resume, and no disconnect will be involved if reset completes > successfully. The code path still has to be coded. Basically usb_resume() must be extended to resume devices from a state analogous to D3cold. > >> The driver loaded again with firmware and the device still could work, is Right? > > > > No. All settings user space has done will be lost. > > > >> I have no a such device to do test. Just from guess. The point is whether > >> resuming the device without loading firmware will fail. > > > > It must. Interfaces can vanish and the device class can change. > > There's nothing to remain bound to. > > If only interfaces may vanish, how about store the user setting things > inside usb_device instance of the interfaces? 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. Regards Oliver -- 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
