On Wed, 25 Nov 2009, Oliver Neukum wrote: > > 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. > > That's better. Will this actually create the uevents you want? > > 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. > > That would mean carry information about the reason reset_resume() > was called into the drivers. And it would lead to a lot of code duplication. > And to drivers that ignore the issue but shouldn't do so. All right. > > 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. > > Not good, but we can at least return an error. Nothing happens to such errors. There may be a message in the system log but that's all. This reminds me... In your autosuspend additions to the various networking and serial drivers, did you set intf->needs_remote_wakeup dynamically? If an interface is down or a serial device is closed then remote wakeup isn't needed, otherwise it is. This will affect the kinds of autosuspends and autoresumes we can perform. 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
