I agree, but because it's possible to have many different hardware for the same class driver, you can't predict if all of them will be not broken. So in this case, each USB class driver should have the reset-resume callback. A broken device can be a device which doesn't resume correctly 1 time per thousand (due to timing reason or anything else). Today, this single resume failure is enough to stuck the device (suspended forever). because mobile systems are more and more PM agressive, I think we could see this problem occurring more often. Unbind/rebind is here as a fallback mechanism for drivers that don't know how to restore device after resume failure, and it works pretty well for system PM. For runtime PM, half of the work is done, interface is declared as needs_rebind but never rebind. So either the rebind work should be completed for PM runtime or an other solution found (logical disconnect, reset_resume mandatory...). But I think this dead end should be fixed. Regards, Loic Poulain ________________________________________ From: Peter Chen [peter.chen@xxxxxxxxxxxxx] Sent: Thursday, March 06, 2014 2:10 AM To: Alan Stern Cc: Poulain, Loic; linux-usb@xxxxxxxxxxxxxxx Subject: Re: BUG: USB Reset-Resume Mechanism does not work for runtime resume On Wed, Mar 05, 2014 at 11:26:06AM -0500, Alan Stern wrote: > On Wed, 5 Mar 2014, Poulain, Loic wrote: > > > + function 'do_rebind_interface' is in charge of unbind and rebind the interfaces with the 'need_binfind' flag set. > > + However this method is only called in 'usb_resume_complete'. > > + Problem is that 'usb_resume_complete' is a dev_pm_ops callback (core/usb.h) used by the System PM core which is never called in a runtime PM scenario. > > + So interfaces remain suspended forever (or until the next PM system suspend/resume), device is unusable. > > (unbinding/rebinding manually the interface via sysfs recovers the device) > > > > Could you please let me know if it's the expected behavior or a real issue. Should we not call 'do_rebind_interface' in the runtime resume sequence? > > I suspect this is an oversight. > > Still, implementing it would be difficult. In usb_runtime_resume, the > device lock may or may not already be held. Therefore we cannot simply > lock the device and call do_rebind_interfaces. > > Using a work queue for this seems like overkill (and it seems fragile). > I don't know what we should do. > If the autosuspend supported device can't respond resume correctly, eg, after resume, it can't respond GET_STATUS correctly in this case, the .reset_resume interface is a must for class driver, it just like a workaround for broken hardware. -- Best Regards, Peter Chen --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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
