On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork <bjorn@xxxxxxx> wrote: > Ming Lei <ming.lei@xxxxxxxxxxxxx> writes: > > 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. The idea should be fine, but may cause regression of user space, suppose one device with suspend failure can be across suspend-resume cycle and work well before, but it is no longer with your forced rebinding. > > 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. I agree, resume() of driver has to handle the suspend failure if there is the failure returned from suspend(). Thanks, -- Ming Lei -- 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
