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
| ||
|
Date: Fri, 4 Mar 2016 03:15:59 +0100 From: "Rafael J. Wysocki" <rafael@...nel.org> To: Viresh Kumar <viresh.kumar@...aro.org> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM list <linux-pm@...r.kernel.org>, Juri Lelli <juri.lelli@....com>, Steve Muckle <steve.muckle@...aro.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, Vincent Guittot <vincent.guittot@...aro.org>, Michael Turquette <mturquette@...libre.com> Subject: Re: [PATCH 5/6] cpufreq: Support for fast frequency switching On Thu, Mar 3, 2016 at 7:00 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote: > On 02-03-16, 03:12, Rafael J. Wysocki wrote: >> Index: linux-pm/drivers/cpufreq/cpufreq.c >> =================================================================== >> --- linux-pm.orig/drivers/cpufreq/cpufreq.c >> +++ linux-pm/drivers/cpufreq/cpufreq.c >> @@ -1772,6 +1772,39 @@ EXPORT_SYMBOL(cpufreq_unregister_notifie >> * GOVERNORS * >> *********************************************************************/ >> >> +/** >> + * cpufreq_driver_fast_switch - Carry out a fast CPU frequency switch. >> + * @policy: cpufreq policy to switch the frequency for. >> + * @target_freq: New frequency to set (may be approximate). >> + * @relation: Relation to use for frequency selection. >> + * >> + * Carry out a fast frequency switch from interrupt context. >> + * >> + * This function must not be called if policy->fast_switch_possible is unset. >> + * >> + * Governors calling this function must guarantee that it will never be invoked >> + * twice in parallel for the same policy and that it will never be called in >> + * parallel with either ->target() or ->target_index() for the same policy. >> + * >> + * If CPUFREQ_ENTRY_INVALID is returned by the driver's ->fast_switch() >> + * callback, the hardware configuration must be preserved. >> + */ >> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >> + unsigned int target_freq, unsigned int relation) >> +{ >> + unsigned int freq; >> + >> + if (target_freq == policy->cur) > > Maybe an unlikely() here ? > >> + return; >> + >> + freq = cpufreq_driver->fast_switch(policy, target_freq, relation); >> + if (freq != CPUFREQ_ENTRY_INVALID) { >> + policy->cur = freq; > > Hmm.. What will happen to the code relying on the cpufreq-notifiers > now ? It will have a problem. For that code it's like the CPU changing the frequency and not telling it (which is not unusual for that matter). Thanks, Rafael
Powered by blists - more mailing lists