To test the patch, I tried it with the btusb driver, and forced manually the resume issue with one interface (intf 0) every five resume call. With this patch, the interface is correctly unbind/rebind. Then, the upper layer (here android) is able to retrieve the device.
However, btusb driver itself doesn't seem compatible with the rebind mechanism. Indeed, When a real resume fails, all the interfaces of a same device are marked for rebind. The btusb driver works with two interfaces, it claims the "intf 1" in the "intf 0" probe and releases the two interfaces at the same time in the disconnect callback. However the rebind mechanism unbind/bind the device's interfaces sequentially. (cf do_rebind_interfaces), for the btusb case, it means: 1. unbind intf 0 2. bind intf 0 3. unbind intf 1 4. bind inf 1 At point 2. btusb probes intf 0, and tries to claim the intf 1 which is not yet unbind, so the intf 0 probe fails (interface 1 busy). At point 4. the busb probes the intf 1, since it's not the "main interface", it fails and returns -ENODEV, waiting for the intf0 probe. I don't know if it is a btusb driver implementation issue or a usb core problem. Two fixes are possible. - Fix the btusb driver, make it compatible with any probe sequence, "intf 0" first or "intf 1" first. (However, may several drivers have the same behavior) - Fix the rebind mechanism, unbind all the interfaces first then probe them all. Regarding, the rebind patch itself, it's ok for me with the forced software failure test. But should be completed with an other patch or new patchset for the btusb driver (at least). Regards, Loic Poulain ________________________________________ From: Alan Stern [st...@rowland.harvard.edu] Sent: Tuesday, March 11, 2014 3:14 PM To: Poulain, Loic Cc: linux-usb@vger.kernel.org; oneu...@suse.de; gre...@linuxfoundation.org Subject: Re: [PATCHv2] rebind: Add rebind mechanism for runtime-resume On Tue, 11 Mar 2014, Poulain, Loic wrote: > Despite the needs_rebind flag, the interface rebind was never > done for the PM runtime resume. This patch fixes this issue > by triggering the rebind in usb runtime resume. > > The rebind procedure needs to be called with the device lock. > However, depending the call path (remote wakeup, local resume), > the device lock may or may not already be held in usb runtime > resume. So, use a work queue to take the lock unconditionally. > Protect this work against any deadlock in the same way as > reset_device. > > Signed-off-by: Loic Poulain <loic.poul...@intel.com> This patch looks okay now. Have you tested it with btusb? What was the result? Alan Stern --------------------------------------------------------------------- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
