Re: musb RPM sleep-while-atomic in 4.9-rc1

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161104 07:16]:
> On Thu, Nov 03, 2016 at 02:26:35PM -0700, Tony Lindgren wrote:
> > OK. Sorry for the delay responding, had my motherboard fail
> > over the weekend..
> 
> Ouch. Hope the recovery process wasn't too painful.

Only the usual scratches on my knuckles :)

> > > How about using a work struct and synchronous get for the deferred case?
> > 
> > Here's the patch updated to use the existing finish_resume_work.
> > Is that along the lines you were thinking?
> 
> Along those lines, yes, but I'm not sure about reusing
> finish_resume_work currently used to deassert resume signalling only.

OK I'll drop the changes for the other ones. Those can be
then combined later as needed once we're done with fixes.

> If work is already queued it seems you could end up deasserting resume
> prematurely for example. It currently also add unnecessary latency to
> other deferred work.

Yeah good point so best to keep this one strictly limited to
resume work.

> You also forgot to queue musb_host_finish_resume() from
> musb_port_suspend() which looks like it would break port resume.

Oh OK will take a look. Might be best to leave that one out
that change for now.

> > +	struct musb_pending_work *w;
> > +	unsigned long flags;
> > +
> > +	if (!callback)
> > +		return;
> 
> WARN_ON (e.g. in case someone switches the arguments)?

Sure. Will fix also your other comments and make it into a
more minimal patch for fixes.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html