All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	Dmitry Torokhov <dtor@chromium.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] cpufreq-dt: defer probing if OPP table is not ready
Date: Wed, 24 Dec 2014 10:58:21 -0600	[thread overview]
Message-ID: <549AF0AD.4070209@ti.com> (raw)
In-Reply-To: <CAKohpokj=u-VhNsW1ZoRsjjPEioMO6FqzVEL3y-7vDCt07cjKw@mail.gmail.com>

On 12/16/2014 10:37 PM, Viresh Kumar wrote:
> On 17 December 2014 at 04:39, Dmitry Torokhov <dtor@chromium.org> wrote:
>> cpufreq-dt driver supports mode when OPP table is provided by platform
>> code and not device tree. However on certain platforms code that fills
>> OPP table may run after cpufreq driver tries to initialize, so let's
>> report -EPROBE_DEFER if we do not find any entires in OPP table for the
>> CPU.
>>
>> Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
>> ---
>>  drivers/cpufreq/cpufreq-dt.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
>> index f56147a..fde97d6 100644
>> --- a/drivers/cpufreq/cpufreq-dt.c
>> +++ b/drivers/cpufreq/cpufreq-dt.c
>> @@ -211,6 +211,17 @@ static int cpufreq_init(struct cpufreq_policy *policy)
>>         /* OPPs might be populated at runtime, don't check for error here */
>>         of_init_opp_table(cpu_dev);
>>
>> +       /*
>> +        * But we need OPP table to function so if it is not there let's
>> +        * give platform code chance to provide it for us.
>> +        */
>> +       ret = dev_pm_opp_get_opp_count(cpu_dev);
>> +       if (ret <= 0) {
>> +               pr_debug("OPP table is not ready, deferring probe\n");
>> +               ret = -EPROBE_DEFER;
>> +               goto out_free_opp;
Umm.. why would I be here? because of_init_opp_table(cpu_dev) did not
find any OPPs at all. but that is OK, coz, we expect dynamic addition
of OPPs by someone else... now,

case 1:
if I did have few OPPs in DT (of_init_opp_table) and cpufreq_init gets
called *before* my dynamic OPPs are added(example based on efuse
entries) -> I'd already have built my dev_pm_opp_init_cpufreq_table
and that wont be accurate. but at that point dev_pm_opp_get_opp_count
cant fail either.. and if cpufreq_init was called *after* dynamic OPPs
are added - correct table, AND dev_pm_opp_get_opp_count wont fail either.

case 2:
If I had 0 OPPs in DT (of_init_opp_table fails) and cpufreq_init gets
called *before* my dynamic OPPs are added(example based on efuse
entries) -> doing a goto out_free_opp and of_free_opp_table is of no
use at all..

case 3:
If I had 0 OPPs in DT (of_init_opp_table fails) and cpufreq_init gets
called *after* my dynamic OPPs are added(example based on efuse
entries) -> I wont have error dev_pm_opp_get_opp_count.

So, you'd better want to introduce an intermediate goto for of_node_put

Also, please use dev_dbg instead of pr_*, since you already have
cpu_dev pointer.

>> +       }
>> +
>>         priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>>         if (!priv) {
>>                 ret = -ENOMEM;
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 


-- 
Regards,
Nishanth Menon

  reply	other threads:[~2014-12-24 16:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 23:09 [PATCH 0/4] Allow cpufreq-dt to defer probe if OPP table is not ready Dmitry Torokhov
2014-12-16 23:09 ` [PATCH 1/4] PM / OPP: add some lockdep annotations Dmitry Torokhov
2014-12-17  4:10   ` Viresh Kumar
2014-12-24 16:28   ` Nishanth Menon
2014-12-24 16:28     ` Nishanth Menon
2014-12-16 23:09 ` [PATCH 2/4] PM / OPP: fix warning in of_free_opp_table Dmitry Torokhov
2014-12-17  4:28   ` Viresh Kumar
2014-12-24 16:42     ` Nishanth Menon
2014-12-16 23:09 ` [PATCH 3/4] PM / OPP: take RCU lock in dev_pm_opp_get_opp_count Dmitry Torokhov
2014-12-17  4:36   ` Viresh Kumar
2014-12-17 17:28     ` Dmitry Torokhov
2014-12-18  2:11       ` Viresh Kumar
2014-12-17 23:47     ` Paul E. McKenney
2014-12-18  2:11       ` Viresh Kumar
2014-12-24 16:48   ` Nishanth Menon
2014-12-24 16:48     ` Nishanth Menon
2014-12-24 17:09     ` Dmitry Torokhov
2014-12-24 17:16       ` Nishanth Menon
2014-12-24 17:31         ` Dmitry Torokhov
2014-12-24 17:37           ` Nishanth Menon
2014-12-24 17:44             ` Dmitry Torokhov
2014-12-24 20:37               ` Nishanth Menon
2014-12-27 20:34                 ` Rafael J. Wysocki
2014-12-16 23:09 ` [PATCH 4/4] cpufreq-dt: defer probing if OPP table is not ready Dmitry Torokhov
2014-12-17  4:37   ` Viresh Kumar
2014-12-24 16:58     ` Nishanth Menon [this message]
2014-12-17  4:42 ` [PATCH 0/4] Allow cpufreq-dt to defer probe " Viresh Kumar

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=549AF0AD.4070209@ti.com \
    --to=nm@ti.com \
    --cc=dtor@chromium.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rjw@rjwysocki.net \
    --cc=stefan.wahren@i2se.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=viresh.kumar@linaro.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.