On Thursday 19 July 2012 18:58:38 Ming Lei wrote:
> On Thu, Jul 19, 2012 at 5:33 PM, Oliver Neukum <oneu...@suse.de> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
