linux-kernel - Re: [V2][PATCH] cpufreq: dt: check the -EPROBE_DEFER error returned by dev_pm_opp_of_cpumask_add

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] [day] [month] [year] [list]

Message-ID: <20210325071254.5f55i2dpsslkfwyz@vireshk-i7>
Date:   Thu, 25 Mar 2021 12:42:54 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     quanyang.wang@...driver.com
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [V2][PATCH] cpufreq: dt: check the -EPROBE_DEFER error returned
 by dev_pm_opp_of_cpumask_add_table

On 25-03-21, 14:42, quanyang.wang@...driver.com wrote:
> From: Quanyang Wang <quanyang.wang@...driver.com>

Made some changes and applied this:

Author: Quanyang Wang <quanyang.wang@...driver.com>
Date:   Thu Mar 25 14:42:08 2021 +0800

    cpufreq: dt: dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER
    
    The function dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER,
    which needs to be propagated to the caller to try probing the driver
    later on.
    
    Signed-off-by: Quanyang Wang <quanyang.wang@...driver.com>
    [ Viresh: Massage changelog/subject, improve code. ]
    Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 drivers/cpufreq/cpufreq-dt.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b1e1bdc63b01..ece52863ba62 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -255,10 +255,15 @@ static int dt_cpufreq_early_init(struct device *dev, int cpu)
         * before updating priv->cpus. Otherwise, we will end up creating
         * duplicate OPPs for the CPUs.
         *
-        * OPPs might be populated at runtime, don't check for error here.
+        * OPPs might be populated at runtime, don't fail for error here unless
+        * it is -EPROBE_DEFER.
         */
-       if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
+       ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+       if (!ret) {
                priv->have_static_opps = true;
+       } else if (ret == -EPROBE_DEFER) {
+               goto out;
+       }
 
        /*
         * The OPP table must be initialized, statically or dynamically, by this

-- 
viresh