linux-kernel - Re: [PATCH 5/8] OPP: Allow multiple clocks for a device

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, 30 Jun 2022 14:32:12 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/8] OPP: Allow multiple clocks for a device

On 10/06/2022 10:20, Viresh Kumar wrote:
> This patch adds support to allow multiple clocks for a device.
> 
> The design is pretty much similar to how this is done for regulators,
> and platforms can supply their own version of the config_clks() callback
> if they have multiple clocks for their device. The core manages the
> calls via opp_table->config_clks() eventually.
> 
> We have kept both "clk" and "clks" fields in the OPP table structure and
> the reason is provided as a comment in _opp_set_clknames(). The same
> isn't done for "rates" though and we use rates[0] at most of the places
> now.
> 
> Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>

(...)

> +	rates = kmalloc_array(count, sizeof(*rates), GFP_KERNEL);
> +	if (!rates)
> +		return -ENOMEM;
> +
> +	ret = of_property_read_u64_array(np, "opp-hz", rates, count);
> +	if (ret) {
> +		pr_err("%s: Error parsing opp-hz: %d\n", __func__, ret);
> +	} else {
> +		/*
> +		 * Rate is defined as an unsigned long in clk API, and so
> +		 * casting explicitly to its type. Must be fixed once rate is 64
> +		 * bit guaranteed in clk API.
> +		 */
> +		for (i = 0; i < count; i++) {
> +			new_opp->rates[i] = (unsigned long)rates[i];
> +
> +			/* This will happen for frequencies > 4.29 GHz */
> +			WARN_ON(new_opp->rates[i] != rates[i]);
> +		}
> +	}
> +
> +	kfree(rates);
> +
> +	return ret;
> +}
> +
>  static int _read_bw(struct dev_pm_opp *new_opp, struct opp_table *opp_table,
>  		    struct device_node *np, bool peak)
>  {
> @@ -812,19 +859,13 @@ static int _read_opp_key(struct dev_pm_opp *new_opp,
>  			 struct opp_table *opp_table, struct device_node *np)
>  {
>  	bool found = false;
> -	u64 rate;
>  	int ret;
>  
> -	ret = of_property_read_u64(np, "opp-hz", &rate);
> -	if (!ret) {
> -		/*
> -		 * Rate is defined as an unsigned long in clk API, and so
> -		 * casting explicitly to its type. Must be fixed once rate is 64
> -		 * bit guaranteed in clk API.
> -		 */
> -		new_opp->rate = (unsigned long)rate;
> +	ret = _read_rate(new_opp, opp_table, np);
> +	if (ret)
> +		return ret;
> +	else if (opp_table->clk_count == 1)

Shouldn't this be >=1? I got several clocks and this one fails.



Best regards,
Krzysztof