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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Johan Hovold <johan@xxxxxxxxxx> [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-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux