linux-kernel - Re: [PATCH 1/2] cpufreq: exynos4x12: Use the common clock framework to set APLL clock rate

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:	Wed, 25 Sep 2013 16:03:22 +0200
From:	Tomasz Figa <t.figa@...sung.com>
To:	Yadwinder Singh Brar <yadi.brar01@...il.com>
Cc:	Lukasz Majewski <l.majewski@...sung.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Lukasz Majewski <l.majewski@...ess.pl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Myungjoo Ham <myungjoo.ham@...sung.com>,
	Kukjin Kim <kgene@...nel.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>
Subject: Re: [PATCH 1/2] cpufreq: exynos4x12: Use the common clock framework to
 set APLL clock rate

Hi Yadwinder,

[resending in plain text, as my mail client somehow reset message 
format from plain back to HTML...]

On Wednesday 25 of September 2013 19:25:54 Yadwinder Singh Brar wrote:
> Hi Lukasz,
> 
> On Wed, Sep 25, 2013 at 4:52 PM, Lukasz Majewski <l.majewski@...sung.com> wrote:
> > In the exynos4x12_set_apll() function, the APLL frequency is set with
> > direct register manipulation.
> >
> > Such approach is not allowed in the common clock framework. The frequency
> > is changed, but the corresponding clock value is not updated. This causes
> > wrong frequency read from cpufreq's cpuinfo_cur_freq sysfs attribute.
> >
> 
> This patch looks incomplete, leaving the driver in untidy state, perhaps its
> doesn't fix the above stated problem completely. what about
> if (!exynos4x12_pms_change(old_index, new_index)) becomes true?
> 
> IMHO, this driver needs lot more work in addition to this patch to cleanly and
> completely move the cpufreq driver to common clock framework.

I agree that the other case needs to be handled as well. Basically the
whole conditional block dependent on exynos4x12_pms_change() can be safely
dropped, because this condition is already handled in PLL driver.

Lukasz is already working on further rework of this driver to clean it up
from legacy code, but this will have to wait for 3.13, as 3.12 is already
in rc stage and only fixes can be accepted for it.

> For fixing this issue urgently, setting CLK_GET_RATE_NOCACHE for apll
> in clk driver can also be quicker fix.

Unfortunately this is not how this flag works. It only makes
clk_get_rate() call ->recalc_rate() operation of the clock instead of
instantly returning cached rate - it doesn't seem to work recursively.

Best regards,
Tomasz

--
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/