> > The genric layer that did request the resumption must be told
> > that this was impossible and the device should be purged.
>
> Last time I did suspend/resume of a system with USB, the hub
> driver _already_ handled that. Presumably it still does.
Sadly I cannot test that. The ohci driver crashes on resumption
on this laptop.
But if we want this to continue we'd have to cope with the new
model. Currently we reenumerate. In that sense we don't
resume anything.
If we under the new model claim that resumption was done,
the current behaviour will not be retained IMHO.
> >>>Now I am puzzeled. There must be some misunderstanding.
> >>>Could you please outline, how we deal with a resumption
> >>>if the devices lost power under the new scheme ?
> >>
> >>By definition, this is "(re)enumeration", not resumption.
> >
> > But how is the state restored ?
>
> I seem to recall pointing you at usb-storage once already,
> as the only USB driver today which needs to do such stuff.
> It has a notion of device identity, based ISTR on serial
> numbers, and saves that state. UTSL.
UTSL ?
Storage is very much a special case.
IMHO we don't want to see this kind of code replicated.
In a way storage does not really have to retain device state.
Storage devices, aside from door locking, don't really have state.
Other types of devices, eg. video or network, do have state at the
device level.
Currently these devices will not resume correctly.
Regards
Oliver
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
