From: Pavel Machek <pavel@ucw.cz>
To: Douglas Anderson <dianders@chromium.org>
Cc: rjw@rjwysocki.net, Dilip Kota <dkota@codeaurora.org>,
dtor@chromium.org, swboyd@chromium.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Len Brown <len.brown@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC PATCH] PM / core: skip suspend next time if resume returns an error
Date: Tue, 2 Oct 2018 10:05:54 +0200 [thread overview]
Message-ID: <20181002080554.GC19677@amd> (raw)
In-Reply-To: <20180927203523.60856-1-dianders@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]
Hi!
> In general Linux doesn't behave super great if you get an error while
> executing a device's resume handler. Nothing will come along later
> and and try again to resume the device (and all devices that depend on
> it), so pretty much you're left with a non-functioning device and
> that's not good.
>
> However, even though you'll end up with a non-functioning device we
> still don't consider resume failures to be fatal to the system. We'll
> keep chugging along and just hope that the device that failed to
> resume wasn't too critical. This establishes the precedent that we
> should at least try our best not to fully bork the system after a
> resume failure.
>
> I will argue that the best way to keep the system in the best shape is
> to assume that if a resume callback failed that it did as close to
> no-op as possible. Because of this we should consider the device
> still suspended and shouldn't try to suspend the device again next
> time around. Today that's not what happens. AKA if you have a
> device
I don't think there are many guarantees when device resume fail. It
may have done nothing, and it may have resumed the device almost
fully.
I guess the best option would be to refuse system suspend after some
device failed like that.
That leaves user possibility to debug it...
Pavel--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-10-02 8:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-27 20:35 [RFC PATCH] PM / core: skip suspend next time if resume returns an error Douglas Anderson
2018-10-02 8:05 ` Pavel Machek [this message]
2018-10-02 8:28 ` Rafael J. Wysocki
2018-10-02 21:01 ` Doug Anderson
2018-10-02 21:16 ` Rafael J. Wysocki
2018-10-02 22:16 ` Doug Anderson
2018-10-03 8:46 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181002080554.GC19677@amd \
--to=pavel@ucw.cz \
--cc=dianders@chromium.org \
--cc=dkota@codeaurora.org \
--cc=dtor@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.