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:	Mon, 2 Jun 2014 15:31:20 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arvind Chauhan <arvind.chauhan@....com>,
	Stephen Warren <swarren@...dia.com>,
	Doug Anderson <dianders@...omium.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Peter De Schrijver <pdeschrijver@...dia.com>
Subject: Re: [PATCH V4 3/3] cpufreq: Tegra: implement intermediate frequency callbacks

On 29 May 2014 23:12, Stephen Warren <swarren@...dotorg.org> wrote:

> E.g. in the following code after the series is applied:
>
>>       ret = clk_set_rate(pll_x_clk, rate * 1000);
>>       /* Restore to earlier frequency on error, i.e. pll_x */
>>       if (ret)
>>               pr_err("Failed to change pll_x to %lu\n", rate);
>>
>>       ret = clk_set_parent(cpu_clk, pll_x_clk);
>
> If the clk_set_rate() failed, we have no idea what the pll_x rate is; I
> don't think the clock API guarantees that zero HW changes have been made
> if the function fails. Yet the code switches the CPU clock back to pll_x
> without attempting to fix the pll_x rate to be the old rate. Perhaps
> there's not much that can be done here though, since if one
> clk_set_rate() failed, perhaps the one to fix it will too.

This was the case here with the existing driver as well. CPUFreq core
expects this today as well and so sends reverse notification in case of
failures.

> I suspect there are other issues, like switching between pll_p/pllx
> might not be restored on error

Another example would be useful..

> and the EMC frequency isn't switched back, etc.

It wasn't in the existing code as well and so left it as is..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ