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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 27 May 2020 17:38:15 -0700 From: Stephen Boyd <sboyd@...nel.org> To: Chanwoo Choi <cw00.choi@...sung.com>, Dmitry Osipenko <digetx@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, Kyungmin Park <kyungmin.park@...sung.com>, Michael Turquette <mturquette@...libre.com>, MyungJoo Ham <myungjoo.ham@...sung.com>, Thierry Reding <thierry.reding@...il.com> Cc: linux-clk@...r.kernel.org, linux-pm@...r.kernel.org, linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v1 2/5] clk: Introduce clk_round_rate_unboundly() Quoting Dmitry Osipenko (2020-05-27 10:57:01) > 27.05.2020 08:55, Stephen Boyd \u043f\u0438\u0448\u0435\u0442: > > Quoting Dmitry Osipenko (2020-03-30 16:16:14) > >> In same cases it may be desired to round clock's rate without taking into > >> account current min/max requests made by the clock's users. One example is > >> building up OPP table based on a possible clock rates. > > > > Shouldn't the OPP table come from firmware/DT? I don't quite understand > > why we're generating OPP tables on top of the rate rounding API. > > clk_round_rate() is supposed to tell us what rate we'll get if we call > > clk_set_rate() with the same arguments. An unboundly version of that > > doesn't make sense. > > The OPP should come from the DT, but unfortunately DT and Tegra's > devfreq driver wasn't designed like that from the start, so it will take > some extra effort to re-do it properly now. I wanted to postpone that > effort a tad and get at least the basics upstreamed for the starter. > > > I wonder if perhaps the clk provider should be populating OPP tables in > > this case? Or basically anything besides adding another clk consumer API > > to solve this problem. Who is the caller? Something later in this > > series? > > I'll try to add a proper OPP table with freqs and voltages, will see how > it goes. We will need to do it sooner or later anyways. So perhaps it's > fine to drop the current approach with the clk_round_rate_unboundly() > and re-focus on a proper OPP implementation. > > Thank you for getting back and replying to this topic :) Alright, it sounds better to me if we can avoid a one off addition to the clk API in favor of implementing a proper OPP table from the start.
Powered by blists - more mailing lists