linux-kernel - Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist

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:   Thu, 14 Oct 2021 15:52:52 +0900
From:   Hector Martin <marcan@...can.st>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Sibi Sankar <sibis@...eaurora.org>,
        Saravana Kannan <saravanak@...gle.com>,
        linux-arm-kernel@...ts.infradead.org,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Sven Peter <sven@...npeter.dev>, Marc Zyngier <maz@...nel.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Catalin Marinas <catalin.marinas@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does
 not exist

On 12/10/2021 18.32, Viresh Kumar wrote:
> On 12-10-21, 18:31, Hector Martin "marcan" wrote:
>> That doesn't work, though, because the CPUs aren't normal devices
>> with runtime-pm. That was the first thing I tried :).
> 
> What's the exact problem with runtime PM here ?

The CPU devices aren't attached to their genpd, so the required OPP
transition fails with the same error.

However, this was easier to fix than I expected. With this patch to
cpufreq-dt, it all works properly, and I can drop the parent genpd
from the clock node and related handling. Thoughts?

commit c4f88743374c1f4678ee7f17fb6cae30ded9ed59
Author: Hector Martin <marcan@...can.st>
Date:   Thu Oct 14 15:47:45 2021 +0900

     cpufreq: dt: Attach CPU devices to power domains
     
     This allows the required-opps mechanism to work for CPU OPP tables,
     triggering specific OPP levels in a parent power domain.
     
     Signed-off-by: Hector Martin <marcan@...can.st>

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 8fcaba541539..5b22846b557d 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -16,6 +16,7 @@
  #include <linux/list.h>
  #include <linux/module.h>
  #include <linux/of.h>
+#include <linux/pm_domain.h>
  #include <linux/pm_opp.h>
  #include <linux/platform_device.h>
  #include <linux/regulator/consumer.h>
@@ -264,6 +265,16 @@ static int dt_cpufreq_early_init(struct device *dev, int cpu)
  		goto out;
  	}
  
+	/*
+	 * Attach the CPU device to its genpd domain (if any), to allow OPP
+	 * dependencies to be satisfied.
+	 */
+	ret = genpd_dev_pm_attach(cpu_dev);
+	if (ret <= 0) {
+		dev_err(cpu_dev, "Failed to attach CPU device to genpd\n");
+		goto out;
+	}
+
  	/*
  	 * The OPP table must be initialized, statically or dynamically, by this
  	 * point.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub