linux-kernel - Re: [PATCH 01/21] opp: Manage empty OPP tables with clk handle

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200409075724.7t3bt3oxaxoygldb@vireshk-i7>
Date:   Thu, 9 Apr 2020 13:27:24 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rajendra Nayak <rnayak@...eaurora.org>
Cc:     sboyd@...nel.org, bjorn.andersson@...aro.org, agross@...nel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/21] opp: Manage empty OPP tables with clk handle

On 08-04-20, 19:16, Rajendra Nayak wrote:
> With OPP core now supporting DVFS for IO devices, we have instances of
> IO devices (same IP block) which require an OPP on some platforms/SoCs

By OPP you mean both freq and voltage here ?

> while just needing to scale the clock on some others.

And only freq here ?

> In order to avoid conditional code in every driver which supports such
> devices (to check for availability of OPPs and then deciding to do
> either dev_pm_opp_set_rate() or clk_set_rate()) add support to manage
> empty OPP tables with a clk handle.

Why can't these devices have an opp table with just rate mentioned in each node
?

> This makes dev_pm_opp_set_rate() equivalent of a clk_set_rate() for
> devices with just a clk and no OPPs specified, and makes
> dev_pm_opp_set_rate(0) bail out without throwing an error.
> 
> Signed-off-by: Rajendra Nayak <rnayak@...eaurora.org>
> ---
>  drivers/opp/core.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index ba43e6a..e4f01e7 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -819,6 +819,8 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>  	if (unlikely(!target_freq)) {
>  		if (opp_table->required_opp_tables) {
>  			ret = _set_required_opps(dev, opp_table, NULL);
> +		} else if (!_get_opp_count(opp_table)) {
> +			return 0;

Why should anyone call this with target_freq = 0 ? I know it was required to
drop votes in the above case, but why here ?

>  		} else {
>  			dev_err(dev, "target frequency can't be 0\n");
>  			ret = -EINVAL;
> @@ -849,6 +851,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>  		goto put_opp_table;
>  	}
>  
> +	/*
> +	 * For IO devices which require an OPP on some platforms/SoCs
> +	 * while just needing to scale the clock on some others
> +	 * we look for empty OPP tables with just a clock handle and
> +	 * scale only the clk. This makes dev_pm_opp_set_rate()
> +	 * equivalent to a clk_set_rate()
> +	 */
> +	if (!_get_opp_count(opp_table)) {
> +		ret = _generic_set_opp_clk_only(dev, clk, freq);
> +		goto put_opp_table;
> +	}
> +

Is this enough? _of_add_opp_table_v2() returns with error if there is no OPP
node within the table. Please give an example of how DT looks for the case you
want to support.

>  	temp_freq = old_freq;
>  	old_opp = _find_freq_ceil(opp_table, &temp_freq);
>  	if (IS_ERR(old_opp)) {
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation

-- 
viresh