linux-kernel - Re: [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration

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:	Tue, 19 Nov 2013 19:56:26 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Nishanth Menon <nm@...com>
Cc:	Shawn Guo <shawn.guo@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Carlos Hernandez <ceh@...com>
Subject: Re: [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency when
 booting with a mismatched bootloader configuration

On 19 November 2013 19:46, Nishanth Menon <nm@...com> wrote:
> Consider something like userspace governor selection -> the device at
> boot will probably remain in an unknown/"invalid" configuration till
> the very first transition attempt. I am less worried about the stats
> than not following what the hardware description is (as stated by
> device tree/other forms).
>
> I staunchly disagree that at a point of mismatch detection, we just
> refuse to load up cpufreq governor -even though we know from device
> tree/other alternative entries what the hardware behavior is supposed
> to be. To refuse to loadup to a known configuration is considering the
> "valid configuration" data provided to the driver is wrong - an
> equivalent(considering the i2c example) is that if i2c driver sees bus
> configured for 3.4MHz and was asked to use 100KHz, it just refuses to
> load up!

CPU looks to be a bit different in that aspect as compared to I2C. We
aren't really sure if I2C will work at the existing freq but we are 100%
sure that current freq of CPU is valid enough, otherwise we wouldn't
have reached to this point.. :)

> The above two are fair comments -> but that implies that policy->cur
> population should no longer be the responsibility of cpufreq drivers
> and be the responsibility of cpufreq core. are we stating we want to
> move that to cpufreq core?

I am sure you want to have a look at this:

commit da60ce9f2faca87013fd3cab1c3bed5183608c3d
Author: Viresh Kumar <viresh.kumar@...aro.org>
Date:   Thu Oct 3 20:28:30 2013 +0530

    cpufreq: call cpufreq_driver->get() after calling ->init()

    Almost all drivers set policy->cur with current CPU frequency in
their ->init()
    part. This can be done for all of them at core level and so they
wouldn't need
    to do it.

    This patch adds supporting code in cpufreq core for calling get()
after we have
    called init() for a policy.

    Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
---
 drivers/cpufreq/cpufreq.c | 11 +++++++++++
 1 file changed, 11 insertions(+)
--
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/