[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1109111636410.21533-100000@netrider.rowland.org>
Date: Sun, 11 Sep 2011 16:44:31 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Ming Lei <tom.leiming@...il.com>
cc: rjw@...k.pl, <linux-pm@...ts.linux-foundation.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] PM/runtime: handle ->runtime_suspend failure correctly
On Sat, 10 Sep 2011 tom.leiming@...il.com wrote:
> From: Ming Lei <tom.leiming@...il.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.
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.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists