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. 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. I am not going to fight this any longer. The per-driver PMSG_IS_AUTO(message) testing is an ugly workround for a core problem, but they are already all over the place... Still, please make sure the drivers all return 0 if they are pretending to suspend. No error code return if the driver ignores the error. Bjørn -- 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
