On Tue, 24 Nov 2009, Oliver Neukum wrote: > Am Dienstag, 24. November 2009 16:44:53 schrieb Alan Stern: > > > For this reason drivers are written with the expectation that > > > reset_resume() will not be called as a result of a remote wakeup. I think > > > usbcore should not attempt to use reset_resume() if a remote wakeup leads > > > to a reset. > > > > How is calling a reset_resume method any worse than going through an > > unbind/rebind cycle? Either way, the device's data will be lost. > > If the device is disconnected everything is clear. A hotplug event > will be issued and data loss can be expected. Yes, that's true. There is a snag, unfortunately. The new runtime PM framework doesn't offer any convenient way to provide a reason for a runtime resume -- nothing like the pm_message_t argument. Unless we do something inelegant like storing the reason in the usb_device structure, there will be no way to distinguish a user-generated resume (writing "on" to /sys/.../power/level) from an autoresume from a remote wakeup. Hence there will be no way to tell whether or not to attempt a reset-resume. (In fact, even if there were a way to provide this information, it couldn't be reliable. Remote wakeup can race with autoresume.) Likewise, there's no way to provide a reason for a runtime suspend. This isn't so important, because currently the only runtime suspends we do are autosuspends. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
