On Tue, 5 Mar 2013, Bjørn Mork wrote: > Ming Lei <ming.lei@xxxxxxxxxxxxx> writes: > > > Yes, USB core will flush any outstanding URBs, but the driver still need > > to deal with suspend failure carefully, for example, suppose usb_resume() > > is called in suspend failure path, and the submitted URBs are killed > > by USB core later. But after the device is wakeup, and the resume() will > > do nothing since the suspend count is leaked. So it is what the patches > > are fixing, and it is better to not depend on the default flushing URBs of > > USB core. > > I am starting to wonder why the USB core has combined system suspend and > runtime suspend if we are going to end up with every driver testing > PMSG_IS_AUTO(message) and selecting a completely different code path. Mainly for historical reasons. System suspend existed long before runtime suspend did. When runtime suspend was added, it piggybacked off the existing code. Furthermore, originally there was no requirement that system suspend always succeed; that was added later. Also, the code paths are not completely different. They differ mainly in their error handling. But when you think about it, how serious an error can you encounter when you try to _stop_ using a device? > You are right that we will end up with problems if usbnet_resume is > called for a device usbnet hasn't suspended. But I'd still claim that > is a bug in the USB core, which is the one that decided to ignore the > suspend error and still call resume. > > I guess proper error handling here require the USB core to see the > interface driver as dead if it fails to suspend on system suspend, and > do forced rebinding on resume. You are welcome to submit a patch to do this. It shouldn't be hard; we already have a flag indicating that an interface needs to be unbound at reprobed at resume time. You can update the kerneldoc in addition; as you noticed, it currently does not describe the actual code completely accurately. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
