* Johan Hovold <johan@xxxxxxxxxx> [161108 10:09]: > On Mon, Nov 07, 2016 at 02:50:18PM -0700, Tony Lindgren wrote: > > @@ -2604,6 +2669,9 @@ static int musb_resume(struct device *dev) > > mask = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_FSDEV | MUSB_DEVCTL_LSDEV; > > if ((devctl & mask) != (musb->context.devctl & mask)) > > musb->port1_status = 0; > > + > > + schedule_delayed_work(&musb->pending_resume_work, 0); > > + > > The interactions with system suspend looks a bit suspicious. It seems > you need to drain any pending resume work on suspend for example. > > And then the above should not be needed, right? Hmm that's an interesting idea. I think that would allow us to get rid of the delayed work if we check the list both on resume and suspend :) > In fact, the dsps timer must also be cancelled on suspend, or you could > end up calling dsps_check_status() while suspended (it is currently not > cancelled until the parent device is suspended, which could be too > late). And then this should no longer be an issue either. I'll take a look and will also check the other comments. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
