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]

Message-ID: <CAKohponO7M6rYoPt=ePNTZh=y+iU=BEbFWBqxr1JQPbVptvgXA@mail.gmail.com>
Date:	Tue, 19 Nov 2013 21:02:20 +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 20:29, Nishanth Menon <nm@...com> wrote:
> Not completely true - reaching probe after boot in a few seconds may
> not mean that system will remain stable at that frequency for longer
> duration. From a silicon vendor perspective, I do know that we
> gaurentee the discrete frequencies in the data manual (and that gets
> populated in devicetree and hence in freq_table), but we will not
> guarentee any other frequency to be functional for any length of time.
> in short, if a actual product is manufactured and operational at a
> frequency we do not "officially support", there is a risk associated
> with that. just a boot on a few development systems do not ever
> guarentee productization capability.

Maybe for a long duration system isn't stable enough but should be
stable for few seconds Atleast?

As soon as ->init() of driver is called we will get a call to:
cpufreq_set_policy() from cpufreq_init_policy(). And we will execute
this for sure:

ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);

On this call if the current freq is lesser or greater than policy limits,
then we will fix it straight away.. Otherwise whichever the governor
is, we will change the freq to any from freq-table very soon..

So, we need a real example of unstable system which really
requires your patch. Otherwise I feel that we will not face any problems
at all..

> So, to summarize: what is our overall strategy here? to move to a
> frequency matched in freq_table OR just giveup? I can try and respin
> accordingly.

I want cpufreq-stats to be fixed with something else, might be something
similar to the patch I have sent..

But this stuff can be left 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/