From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: musb RPM sleep-while-atomic in 4.9-rc1 Date: Mon, 7 Nov 2016 11:28:38 -0700 Message-ID: <20161107182838.GD2428@atomide.com> References: <20161027151446.ffj6w2tydf6ymv7c@atomide.com> <20161027164416.GL12024@localhost> <20161027174016.43twztwekvb3b25t@atomide.com> <20161027184507.GM12024@localhost> <20161027191552.tuutyslp5qtu2b4f@atomide.com> <20161028094428.GO12024@localhost> <20161028181318.umwn3rx55pg2cvwd@atomide.com> <20161031114921.GB4254@localhost> <20161103212635.GC21430@atomide.com> <20161104141615.GA16119@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20161104141615.GA16119@localhost> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Johan Hovold Cc: Bin Liu , linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ladislav Michl , linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-omap@vger.kernel.org * Johan Hovold [161104 07:16]: > Perhaps sleep in musb_host_finish_resume() instead of always adding this > delay which is only needed for deasserting resume signalling and not for > generic (runtime) resume work (if you decide to use a common work > queue). Looking at your comments again, this is a good idea for future use. > But why schedule from resume at all? It seems you could just schedule > the deferred-work processing directly after having registered a > callback. But with this one we need to schedule the deferred work only from resume as waking up things can take a while potentially. Anyways, I'll post all the pending fixes as a new thread shortly. 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