linux-kernel - Re: [PATCH 2/2] OPP/pmdomain: Fix the assignment of the required-devs

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: <20240903105321.suosbhkkkylfw4bv@vireshk-i7>
Date: Tue, 3 Sep 2024 16:23:21 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
	Stephen Boyd <sboyd@...nel.org>,
	Dikshita Agarwal <quic_dikshita@...cinc.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <quic_kdybcio@...cinc.com>,
	Nikunj Kela <nkela@...cinc.com>,
	Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Mikko Perttunen <mperttunen@...dia.com>,
	Jonathan Hunter <jonathanh@...dia.com>,
	Stephan Gerhold <stephan@...hold.net>,
	Ilia Lin <ilia.lin@...nel.org>,
	Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
	Vikash Garodia <quic_vgarodia@...cinc.com>,
	linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] OPP/pmdomain: Fix the assignment of the required-devs

On 03-09-24, 11:54, Ulf Hansson wrote:
> Let me try to elaborate a bit more.
> 
> In the current code, genpd_find_opp_table() tries to find an OPP table
> for the genpd that the device is getting attached to. Then genpd
> passes that OPP table via devm_pm_opp_set_config(), to let the OPP
> core to hook up a required-dev for it. This was a naive approach, as
> that OPP table may not be the one that actually corresponds to a
> required-opps for the required-dev. Consider the below in DT.
> 
>         opp_table_devA: opp-table-devA {
>                 compatible = "operating-points-v2";
> 
>                 opp-devA-50 {
>                         opp-hz = /bits/ 64 <2500>;
>                         required-opps = <&opp_pd_50>; //corresponds to
> pd_perf1's OPP table
>                 };
>                ....
> 
>         devA {
>                 compatible = "foo,bar";
>                 power-domains = <&pd_perf0>, <&pd_perf1>; //both
> pd_perf0 and pd_perf1 has OPP tables.
>                 power-domain-names = "perf0", "perf1";
>                 operating-points-v2 = <&opp_table_devA>;
>         };

I think another way forward would be to send an index along with
required-dev information (now that you do it one by one). That index
would be the index of the genpd in the genpd-list for the device. That
would make it work, isn't it ?

I would like to avoid (another) callback from the OPP core, we already
have few of them and I don't like them a lot. Moreover, genpd should
be able to get the right required opp, with an index. Unless I am
mistaken and this still doesn't solve it :)

> To make sure we assign the correct required-dev for cases like the
> above, we need to let the OPP core to iterate through the available
> required-opps and see if some of them are corresponding to the OPP
> table for the genpd the required-dev belongs too.
> 
> To manage this in a non-genpd specific way, I added another callback
> in struct dev_pm_opp_config. In this way, it should work for any
> future possible required-devs types too, I think.

-- 
viresh