From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: "Fu,
Zhonghui" <zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Emmanuel Grumbach
<egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
"linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Rafael J. Wysocki"
<rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously
Date: Mon, 24 Aug 2015 09:38:38 +0200 [thread overview]
Message-ID: <1440401918.3735.0.camel@sipsolutions.net> (raw)
In-Reply-To: <55DA9374.2060909-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Mon, 2015-08-24 at 11:45 +0800, Fu, Zhonghui wrote:
>
> On 2015/8/17 16:46, Arend van Spriel wrote:
> > + Rafael
> >
> > On 08/17/2015 09:29 AM, Johannes Berg wrote:
> > > On Mon, 2015-08-17 at 09:48 +0800, Fu, Zhonghui wrote:
> > > >
> > > > The suspend/resume timing of wiphy device and related devices
> > > > will be
> > > > ensured by their parent/child relationship. So, enabling wiphy
> > > > device
> > > > to suspend/resume asynchronously does not change any
> > > > dependency. It
> > > > can only take advantage of multicore and improve system
> > > > suspend/resume speed.
> > > >
> > >
> > > You're going to have to explain that to me, because I don't see
> > > that.
> > > All I see is that when looking at a device, if async is possible,
> > > it
> > > gets added to an async work, and if async is not possible then it
> > > gets
> > > done immediately. Even putting aside the question of whether or
> > > not
> > > async is ordered or not (I don't know), if the wiphy is async and
> > > the
> > > PCI (or other bus) device isn't, then it seems they could get
> > > handled
> > > out of order, no? Or is there some magic code somewhere that I'm
> > > missing that explicitly waits for the async of the parent/child
> > > relationship?
> >
> > This patch got me worried as well. Can't find the magic either.
> > Maybe Rafael can give some hints here.
>
> "dpm_wait_for_children" function will be invoked in
> "__device_suspend", "__device_suspend_late", and
> "__device_suspend_noirq" functions to synchronize the child
> relationship. "dpm_wait" function will be invoked in
> "device_resume_noirq", "device_resume_early", and "device_resume"
> functions to synchronize the parent relationship. If two devices have
> parent/child relationship, but different suspend/resume mode(sync or
> async), this will have no impact to PM timing order between them.
> Because all devices will use "__device_suspend",
> "__device_suspend_late" ... functions to complete their PM
> transition.
>
Ok, good point. For the unaware here, can you please resend with a
commit message amended with some of this information?
thanks,
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-08-24 7:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 5:18 [PATCH] net/wireless: enable wiphy device to suspend/resume asynchronously Fu, Zhonghui
2015-07-30 5:55 ` Emmanuel Grumbach
2015-08-13 13:13 ` Johannes Berg
2015-08-17 1:48 ` Fu, Zhonghui
2015-08-17 7:29 ` Johannes Berg
2015-08-17 8:46 ` Arend van Spriel
2015-08-24 3:45 ` Fu, Zhonghui
[not found] ` <55DA9374.2060909-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2015-08-24 7:38 ` Johannes Berg [this message]
2015-09-19 2:45 ` Fu, Zhonghui
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=1440401918.3735.0.camel@sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=zhonghui.fu-VuQAYsv1563Yd54FQh9/CA@public.gmane.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 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).