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 16:23:20 +0900
From:   Hector Martin <marcan@...can.st>
To:     Viresh Kumar <viresh.kumar@...aro.org>,
        Ulf Hansson <ulf.hansson@...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>, 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 14/10/2021 16.03, Hector Martin wrote:
> On 14/10/2021 15.56, Viresh Kumar wrote:
>>> +	/*
>>> +	 * 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;
>>> +	}
>>> +
>>
>> Other platform do this from some other place I think.
>>
>> Ulf, where should this code be moved ? cpu-clk driver ?
>>
> 
> I see one driver that does this is drivers/clk/qcom/apcs-sdx55.c (via
> dev_pm_domain_attach). Though it only does it for CPU#0; we need to do
> it for all CPUs.

Looking into this further, I'm not sure I like the idea of doing this in 
the clocks driver. There might be locking issues since it gets 
instantiated twice and yet doesn't really itself know what subset of 
CPUs it applies to.

There's another driver that does this: 
drivers/cpuidle/cpuidle-psci-domain.c. That one specifically looks for a 
power domain called "psci". Perhaps it would make sense to make this 
generic in cpufreq-dt as per my prior patch, but explicitly request a 
"cpufreq" domain? That way only devicetrees that opt in to having this 
handled by cpufreq by naming it that way would get this behavior.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ