On 2014-10-13 17:41:50 [-0500], Felipe Balbi wrote: > > That timer deserves to be killed because nobody wants it to wakeup the > > system from suspend. However the Data Abort wouldn't happen if the timer > > would use pm_runtime_get_sync() right? > > correct, but we want to suspend ;-) there is a race here: No doubt about that but I was confused that the timer routine didn't do pm_get_sync() at all. Usually this done before every register access so I was just asking if this piece should be added or if it is not required at all. But then I don't see any pm_get_sync() in URB enqueue for instance so there might be a different strategy :) > mod_timer(); > > /* before mod_timer() expires */ > "echo mem > /sys/power/suspend" > > ->runtime_suspend() > /* clocks are now gated */ > > /* mod_timer() expires and BOOM! */ yes. > > You need a mod_timer() here instead. I will send a patch in a few. > > yeah, I was confused if it should be setup_timer() or mod_timer(). Since > I deleted the timer on suspend, I thought setup_timer() was more > appropriate, no ? Look for "[PATCH] usb: musb: dsps: start OTG timer on resume again" setup_timer() does nothing but assign the private data argument. mod_timer() enqueues the timer back into the timer wheel which is the reverse of del_timer(). On top of that you should check if you we want to the enqueue timer at all (you don't want this in HOSTMODE or if it is not in OTG mode). Sebastian -- 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
