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]
Message-ID: <Y/hyf+/EqEeTu436@niej-dt-7B47>
Date:   Fri, 24 Feb 2023 16:17:03 +0800
From:   Jun Nie <jun.nie@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     cw00.choi@...sung.com, Nishanth Menon <nm@...com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>, linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] OPP: Simplify set_required_opp handling

On Fri, Feb 24, 2023 at 07:47:13AM +0530, Viresh Kumar wrote:
> On 23-02-23, 17:56, Jun Nie wrote:
> > It looks promising. The function get_target_freq_with_cpufreq() can be wrapped
> > to act as set_required_opps() callback.
> 
> > But my case is a bit complicated. CPU opp depends on both genpd opp and
> > devfreq opp.
> 
> I was wondering if we will have such a case soon enough or not :)
>  
> > So the genpd_virt_devs array need
> > to be modified or add another array for devfreq case. While genpd_virt_devs is
> > bounded with genpd directly and coupled with "power-domains" list in
> > device tree.
> > Current required-opp nodes are designed to be aligned with the list. I
> > am considering
> > what's the best way for back compatibility.
> 
> Please look at the top commit here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git opp/propagate
> 
> Will this be enough for your use case ? I will post everything again once we are
> settled on a solution.

For the opp lib, this is right direction. We still need to find a method to
pass devfreq device node to opp lib, just genpd_virt_devs for power domain.
But I am not clear below is the right way yet and this also involves wider
changes. Or the opp's owner, devfreq device can be referred via opp lib?
If so, we do not need to add devfreq-devs to cpu node at all.

		cpu1: cpu@101 {
			compatible = "arm,cortex-a53";
			device_type = "cpu";
			power-domains = <&cpr>;
			power-domain-names = "cpr";
			devfreq-devs = <&cci>;
			devfreq-names = "cci";
			operating-points-v2 = <&cluster1_opp_table>;
		};

		opp-200000000 {
			opp-hz = /bits/ 64 <200000000>;
			required-opps = <&cpr_opp3>, <&cci_opp1>;
		};

> 
> -- 
> viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ