On Wed, Nov 09, 2016 at 04:39:53PM +0100, Johan Hovold wrote: > On Tue, Nov 08, 2016 at 06:26:07PM -0700, Tony Lindgren wrote: > > @@ -2065,6 +2147,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl) > > } > > > > spin_lock_init(&musb->lock); > > + spin_lock_init(&musb->list_lock); > > musb->board_set_power = plat->set_power; > > musb->min_power = plat->min_power; > > musb->ops = plat->platform_ops; > > @@ -2556,6 +2639,7 @@ static int musb_suspend(struct device *dev) > > struct musb *musb = dev_to_musb(dev); > > unsigned long flags; > > > > + WARN_ON(!list_empty(&musb->pending_list)); > > And this also depends on anyone attempting to queue work having first > gotten an RPM reference (so that driver core runtime resumes the device > before calling suspend()). > > But no, there's actually still a window were this could be false when > work is queued while runtime resuming (and eventually is executed from > musb_queue_resume_work()). As you just pointed out that can actually never happen and corresponding code can be removed from musb_queue_resume_work(), so scrap this last paragraph too. :) Johan -- 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
