On Wed, 25 Nov 2009, Oliver Neukum wrote: > I don't think we need the reason. The mere fact that a resumption leads > to a reset while remote wakeup is requested should be enough. Unless > we are resuming from a system sleep, but that's a global event. > > Such a device cannot be used with runtime power management and > this driver unless it is marked quirky, whereby autosuspend with > remote wakeup requested would be prevented. Let me get this straight. You're suggesting that during a runtime resume, if any interface driver requires remote wakeup capability then we should not carry out a reset-resume -- we should let the resume fail and logically disconnect the device. Right? I think that's going too far. We might have a serial interface and a mass-storage interface in the same device; the fact that the serial driver needs remote wakeup shouldn't prevent the mass-storage driver from using reset-resumes. So let's change the suggestion. If an interface driver requires remote wakeup capability then a reset-resume should force the driver to be unbound/rebound. Whether this will generate hotplug events the way you want depends on how the driver is written. Even this seems a little drastic. How about letting the driver decide, instead? If the reset_resume method returns an error, we can mark the interface for rebinding. That will work for both runtime resume and system resume. Except for one detail. We can't do rebinding during an autoresume (i.e., usb_autopm_get_interface()) because we don't own the device lock at such times. 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
