From: "Rafael J. Wysocki" <firstname.lastname@example.org>
To: Alan Stern <email@example.com>
Cc: "Rafael J. Wysocki" <firstname.lastname@example.org>,
Qais Yousef <email@example.com>,
USB list <firstname.lastname@example.org>,
Linux-pm mailing list <email@example.com>,
Kernel development list <firstname.lastname@example.org>
Subject: Re: lockdep warning in urb.c:363 usb_submit_urb
Date: Fri, 03 Apr 2020 17:04:16 +0200 [thread overview]
Message-ID: <2274735.ifPVKiii8o@kreacher> (raw)
On Sunday, March 29, 2020 6:27:38 PM CEST Alan Stern wrote:
> On Sun, 29 Mar 2020, Rafael J. Wysocki wrote:
> > On Sat, Mar 28, 2020 at 8:58 PM Alan Stern <email@example.com> wrote:
> > > Can you give a similarly
> > > succinct outline for how SMART_SUSPEND and LEAVE_SUSPENDED should work?
> > > And also describe how they differ from direct_complete and how they
> > > interact with it? (For example, how does setting both flags differ
> > > from returning a positive value from ->prepare?)
> > I will, but I need some time to do that. Stay tuned.
> You bet!
Sorry for the delay, too much distraction nowadays.
I'll address the other points in your message separately.
The rules for SMART_SUSPEND are as follows:
(a) If SMART_SUSPEND is set and the device is runtime-suspended during system
suspend, it is not expected to be resumed by the core or the middle layer
(subsystem) code unless the latter has a specific reason to do that (e.g.
it knows that the device needs to be reconfigured which cannot be done
without resuming it).
The device can still be resumed when it is needed to suspend a dependent
device, but that cannot happen before the "late suspend" phase.
(b) Drivers that set SMART_SUSPEND are allowed to reuse their PM-runtime
callbacks for system-wide suspend and resume.
That is, they can point either the ->suspend_late or the ->suspend_noirq
callback pointer to the same function as ->runtime_suspend and they can
point either the ->resume_noirq or ->the resume_early callback to the'
same function as ->runtime_resume.
(c) Drivers that set SMART_SUSPEND are alwo allowed to provide special
simplified callbacks for the "freeze" and "thaw" transitions during
hibernation (and restore) and (if they do so) special callbacks for the
[OK, I realize that (b) and (c) are not documented, see the notes below.]
Because of (a), if the device with SMART_SUSPEND set is still runtime-suspended
during the "late" phase of suspend, the core will not invoke the driver's
"late" and "noirq" suspend callbacks directly (*). Middle layer (subsystem)
code is expected to behave accordingly.
Because of (b), if the "late" and "noirq" driver callbacks were skipped during
the "freeze" transition, the core will also avoid invoking the "noirq" and
"early" callbacks provided by the driver during the "thaw" transition and
the callbacks during the "restore" transition will be executed unconditionally
(**). Middle layer code is expected to behave accordingly.
1. I have considered splitting SMART_SUSPEND into two or even three flags
so that (a), (b) and (c) are each associated with a separate flag, but
then I would expect the majority of users to use all of them anyway.
2. LEAVE_SUSPENDED (which may be better renamed to SKIP_RESUME) is kind of
expected to be used along with SMART_SUSPEND unless there is a good enough
reason to avoid using it. I admit that this isn't really straightforward,
maybe the default behavior should be to skip the resume and there should be
FORCE_RESUME instead of LEAVE_SUSPENDED.
3. (*) Under the assumption that either ->suspend_late or ->suspend_noirq
points to the same routine as ->runtime_suspend (and the other is NULL),
invokig that callback for a runtime-suspended device is technically invalid.
In turn, under the assumption that either ->resume_early or ->resume_noirq
points to the same routine as ->runtime_resume (and the other is NULL), it is
valid to invoke that callback if the late/noirq suspend was skipped.
4. (**) If the "freeze" and "thaw" callbacks are simplified, they cannot be
run back-to-back with ->runtime_resume and ->runtime_suspend, respectively.
Thus if "freeze" is skippend, "thaw" must be skipped too. However,
"restore" needs to be prepared to be invoked after "freeze" or
->runtime_suspend (and the state of the device may not match the
callback that ran previously), so it must be special.
5. I agree that skipping the driver level of callbacks depending on what is
provided by the middle layer is inconsistent, but I wanted to take the
users of pm_runtime_force_suspend/resume() into account by letting those
It would be more consistent to expect middle layer code (bus types, PM
domains) to provide either all of the noirq/early/late callbacks, or none
of them and make SMART_SUSPEND and pm_runtime_force_suspend/resume()
next prev parent reply other threads:[~2020-04-03 15:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200325150017.xhabucfo3v6i234o@e107158-lin>
2020-03-25 20:49 ` lockdep warning in urb.c:363 usb_submit_urb Alan Stern
2020-03-25 21:28 ` Rafael J. Wysocki
2020-03-26 12:27 ` Qais Yousef
2020-03-27 20:45 ` Alan Stern
2020-03-28 14:15 ` Rafael J. Wysocki
2020-03-28 19:58 ` Alan Stern
2020-03-29 9:16 ` Rafael J. Wysocki
2020-03-29 13:56 ` Rafael J. Wysocki
2020-03-29 16:27 ` Alan Stern
2020-04-03 15:04 ` Rafael J. Wysocki [this message]
2020-04-03 16:13 ` Rafael J. Wysocki
2020-04-03 16:41 ` Alan Stern
2020-04-03 18:32 ` Rafael J. Wysocki
2020-04-03 20:15 ` Alan Stern
2020-04-06 16:45 ` Rafael J. Wysocki
2020-04-06 20:25 ` Alan Stern
2020-04-09 18:45 ` Rafael J. Wysocki
2020-04-11 2:41 ` Alan Stern
2020-04-13 21:32 ` Rafael J. Wysocki
2020-04-14 13:43 ` Rafael J. Wysocki
2020-04-14 17:47 ` Alan Stern
2020-04-15 22:20 ` Rafael J. Wysocki
2020-04-16 15:18 ` Alan Stern
2020-04-17 9:57 ` Rafael J. Wysocki
2020-04-17 16:10 ` Alan Stern
2020-04-17 21:54 ` Rafael J. Wysocki
2020-04-17 23:37 ` Alan Stern
2020-04-18 9:40 ` Rafael J. Wysocki
2020-04-03 17:08 ` Rafael J. Wysocki
2020-04-20 20:26 ` Alan Stern
2020-04-21 11:15 ` Qais Yousef
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).