> > Nope, it's a definition. Suspend/resume involves preserving > > state. If they didn't keep power, they couldn't keep that state, > > and they had to (re)initialize. Just like unplug/replug. > > This one I don't understand - why do you claim a buspowered device > couldn't keep state over suspend/resume?
Actually I didn't say that for all of them, just the ones on the other side of a bus powered hub: > Suspend is quite different from power-cut as devices are still allowed to > draw up to 0.5mA from the suspended USB (see 9.2.3, USB spec.). Might be enough to handle a bus powered hub, but not on the other side of it: 0.5mA for the hub and four ports is 2.5mA, too much power to draw. So the hub won't provide power to those devices. > While > being enough for a pm-aware microcontroler to keep its state information > (like fn-address, device-config, interface alternate setting) in the > microcontroler registers, it's probably insufficient to keep the firmware > running or even to have an external ram powered. Hence the device _does_ > keep its state, but needs to reload firmware (or parts of) on resume. Maybe. But nobody has yet provided examples of specific products that behave that way, so I remain skeptical. Since device designers know they must retain state with 0.5mA, they design with that in mind. - Dave > And the device might simply use an eeprom to save and restore its state > during suspend/resume. The required state information can be reduced to > only a few bytes - which are easy to write to some eeprom during the > 10ms the device may take to complete suspending. > > Martin > _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
