Then we must refuse any sleep states that want to power down the bus.
No, if the bus powers off the call sequence seen by that driver will be suspend()->disconnect() rather than suspend()->resume().
This will do horrible things if the attached device has considerable state.
Only if the suspend() method is deeply stupid, right? I mean, here's this code which KNOWS it may never have another chance to save that state -- not saving it?
The "prepare for suspend" doesn't mean "you're gonna get a resume, buddy". It means "shut down, but keep enough state to make restarting be fast ... in case you get a resume() instead of disconnect()". That's true for any hot-unpluggable device.
That's a completely routine operation, like unplugging something while it's suspended. You want to tell folk they can't suspend their laptop and THEN unplug all devices/cables?
I don't want to, but apparently it is the case. See this thread:
That's NOT the case. It's not necessary, and it would be user-antagonistic.
Process in D state with USB and swsuspsp
Seems devoid of useful content, like alt-sysrq-t showing what's being blocked ... there are all kinds of ACPI bugs relating to PCI resume, slowly getting resolved, and I think it's likely that's another one of those bugs. Though come to think of it, the self-deadlock in the PM code in this area has never been fixed.
- Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
