lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 2 Jul 2014 17:02:13 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Shawn Guo <shawn.guo@...aro.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arvind Chauhan <arvind.chauhan@....com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-arm-msm@...r.kernel.org, Sachin Kamat <spk.linux@...il.com>,
	Thomas P Abraham <thomas.ab@...sung.com>,
	Nishanth Menon <nm@...com>, Tomasz Figa <t.figa@...sung.com>
Subject: Re: [PATCH 06/14] cpufreq: cpu0: defer probe if clock isn't
 registered yet

On 2 July 2014 11:25, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 2 July 2014 11:23, Shawn Guo <shawn.guo@...aro.org> wrote:
>> On Tue, Jul 01, 2014 at 10:02:35PM +0530, Viresh Kumar wrote:
>
>>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>>> index 4273a5f..b5b8e1c 100644
>>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>>> @@ -150,8 +150,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
>>>
>>>       cpu_clk = clk_get(cpu_dev, NULL);
>>>       if (IS_ERR(cpu_clk)) {
>>> -             ret = PTR_ERR(cpu_clk);
>>
>> If you keep this ...
>>
>>> -             pr_err("failed to get cpu0 clock: %d\n", ret);
>>> +             /*
>>> +              * If cpu's clk node is present, but clock is not yet
>>> +              * registered, we should try defering probe.
>>> +              */
>>> +             if (PTR_ERR(cpu_clk) == -EPROBE_DEFER) {
>>
>> ... you can use 'ret' here ...
>>
>>> +                     dev_err(cpu_dev, "cpu0 clock not ready, retry\n");
>>> +                     ret = -EPROBE_DEFER;
>>
>> ... this can be saved ...
>>
>>> +             } else {
>>> +                     ret = PTR_ERR(cpu_clk);
>>
>> ... and this as well.
>
> All accepted. Thanks.

The motive of this patch is changed completely after what you suggested
and so logs are updated as well:

    cpufreq: cpu0: print relevant error when we defer probe

    Currently, we defer probe if regulator_get() returned -EPROBE_DEFER, i.e.
    regulator isn't registered yet.

    The same is true for clock as well and should be done there.

    Current code already does it, but it wasn't intentional probably.
Its just that
    we are returning the right error with wrong print message.

    Fix print message to convey right error.

    Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 drivers/cpufreq/cpufreq-cpu0.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 4273a5f..0c16b2f 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -151,7 +151,16 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
        cpu_clk = clk_get(cpu_dev, NULL);
        if (IS_ERR(cpu_clk)) {
                ret = PTR_ERR(cpu_clk);
-               pr_err("failed to get cpu0 clock: %d\n", ret);
+
+               /*
+                * If cpu's clk node is present, but clock is not yet
+                * registered, we should try defering probe.
+                */
+               if (ret == -EPROBE_DEFER)
+                       dev_err(cpu_dev, "cpu0 clock not ready, retry\n");
+               else
+                       dev_err(cpu_dev, "failed to get cpu0 clock: %d\n", ret);
+
                goto out_put_reg;
        }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ