> > > The caller -- perhaps sysadmin through sysfs -- had the option
> > > to choose a "suspend", and instead chose a "disconnect".
> > > It only makes sense to respect that choice.
> >
> > We may have no option. Unless I'm mistaken, suspend-to-RAM puts most PCI
> > devices into D3cold.
>
> That'd be a bug. STR isn't supposed to discard state like that; it's
> supposed to leave devices (low-)powered but able to resume
> quickly (give or take a few breaths), not turn them off wholesale.
> Otherwise it'd need to be called suspend-to-disk. :)
Congratulations!
You've just discovered a new system state, tentatively called "suspend-to-ramdisk" >:->
[..]
> > As each device is discovered
> > and initialized, it needs to be reattached to the driver which owned it
> > before. That's essentially what usb_reset_device() does now.
>
> Better yet, when the system uses resume() on those devices then
> no re-enumeration/probing is needed. But I still think the default
> handling of suspend should be disconnect() for drivers that don't
> provide even minimal suspend/resume handlers. So that in those
> cases, resuming should involve re-enumeration.
USB-core will at least have to restore the configuration. Unfortunately
that operation can fail for several reasons.
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
