Am Mittwoch, 25. November 2009 16:48:03 schrieb Alan Stern: > 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? That was my proposal, but stated that bluntly it seems a bit too harsh. > 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. That's better. > 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. > 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. Regards Oliver -- 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
