From: Tejun Heo <tj@kernel.org>
To: qiaozhou <qiaozhou@asrmicro.com>
Cc: linux-pm@vger.kernel.org, Wang Wilbur <wilburwang@asrmicro.com>,
Wu Gang <gangwu@asrmicro.com>,
linux-kernel@vger.kernel.org
Subject: Re: [Question] about patch: don't use [delayed_]work_pending()
Date: Fri, 2 Sep 2016 09:50:07 -0400 [thread overview]
Message-ID: <20160902135007.GF12660@htj.duckdns.org> (raw)
In-Reply-To: <6b2fc72b-f99f-f7f1-3221-093943de0950@asrmicro.com>
Hello,
On Fri, Sep 02, 2016 at 09:17:04AM +0800, qiaozhou wrote:
> > > I don't know whether it's meaningful to still check pending work here, or
> > > it's not suggested to use pm_qos_update_request in this early boot up phase.
> > > Could you help to share some opinions? (I can fix this issue by adding the
> > > current qos value directly instead of default value, though.)
> > Hmmm... but I suppose this is super-early in the boot. Would it make
> > sense to have a static variable (e.g. bool clk_fully_initailized) to
> > gate the cancel_delayed_sync() call?
>
> You're right that it's indeed super-early stage. But currently we can't
> control the gate of can_delayed_work_sync, since it's inside
> pm_qos_update_request. Out of our control. We can choose to not call
> pm_qos_update_request to avoid this issue, and use pm_qos_add_request
> alternatively. Good to have it.
Ah sorry, didn't understand that the offending cancel_sync call is in
the generic part. Hmm... but yeah, we should still be able to take
the same approach. I'll see what's the right thing to gate the
operation there.
Thanks.
--
tejun
next prev parent reply other threads:[~2016-09-02 13:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 9:09 [Question] about patch: don't use [delayed_]work_pending() qiaozhou
2016-09-01 18:45 ` Tejun Heo
2016-09-02 1:17 ` qiaozhou
2016-09-02 13:50 ` Tejun Heo [this message]
2016-09-02 14:21 ` Tejun Heo
2016-09-03 15:27 ` qiaozhou
2016-09-05 5:34 ` qiaozhou
2016-09-05 12:38 ` [PATCH] power: avoid calling cancel_delayed_work_sync() during early boot Tejun Heo
2016-09-05 12:58 ` 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=20160902135007.GF12660@htj.duckdns.org \
--to=tj@kernel.org \
--cc=gangwu@asrmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=qiaozhou@asrmicro.com \
--cc=wilburwang@asrmicro.com \
/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).