Messages in this thread | | | Date | Wed, 14 Sep 2011 09:17:03 +0800 | Subject | Re: [PATCH 2/2] PM/runtime: handle ->runtime_suspend failure correctly | From | Ming Lei <> |
| |
Hi,
On Mon, Sep 12, 2011 at 4:44 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Sat, 10 Sep 2011 tom.leiming@gmail.com wrote: > >> From: Ming Lei <tom.leiming@gmail.com> >> >> If ->runtime_suspend returns -EAGAIN or -EBUSY, the device should >> still be in ACTIVE state, so it is not needed to handle defered >> resume and idle notification to its parent; if ->runtime_suspend >> returns other fatal failure, it doesn't make sense to process defered >> resume and send idle notification to its parent. > >> @@ -422,6 +425,9 @@ static int rpm_suspend(struct device *dev, int rpmflags) >> } >> wake_up_all(&dev->power.wait_queue); >> >> + if (retval) >> + goto out; >> + >> if (dev->power.deferred_resume) { >> rpm_resume(dev, 0); >> retval = -EAGAIN; > > If there's a suspend failure, the deferred_resume flag gets turned off > anyway. But skipping this test won't hurt, and skipping the parent > notification is a good idea.
Yes, I will update the commit log.
> > In fact, it might be even better to put a copy of the wake_up_all() in > the "if (retval)" branch after the suspend callback and then go > directly to out. The "else" branch could then become part of the > straight-through code, not indented.
Good idea, will update this in -v1.
thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |