Patch "cpufreq: Make policy min/max hard requirements" has been added to the 5.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    cpufreq: Make policy min/max hard requirements

to the 5.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     cpufreq-make-policy-min-max-hard-requirements.patch
and it can be found in the queue-5.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 8f00330a1e8710fce315f5560a8dd129bf0abc64
Author: Vincent Donnefort <vincent.donnefort@xxxxxxx>
Date:   Wed Sep 8 15:05:26 2021 +0100

    cpufreq: Make policy min/max hard requirements
    
    [ Upstream commit 15171769069408789a72f9aa9a52cc931b839b56 ]
    
    When applying the policy min/max limits, the requested frequency is
    simply clamped to not be out of range. It means, however, if one of the
    boundaries isn't an available frequency, the frequency resolution can
    return a value out of those limits, depending on the relation used.
    
    e.g. freq{0,1,2} being available frequencies.
    
              freq0  policy->min  freq1  policy->max   freq2
                |        |          |        |           |
              17kHz     18kHz     19kHz     20kHz      21kHz
    
         __resolve_freq(21kHz, CPUFREQ_RELATION_L) -> 21kHz (out of bounds)
         __resolve_freq(17kHz, CPUFREQ_RELATION_H) -> 17kHz (out of bounds)
    
    If, during the policy init, we resolve the requested min/max to existing
    frequencies, we ensure that any CPUFREQ_RELATION_* would resolve to a
    frequency which is inside the policy min/max range.
    
    Making the policy limits rigid helps to introduce the inefficient
    frequencies support. Resolving an inefficient frequency to an efficient
    one should not transgress policy->max (which can be set for thermal
    reason) and having a value we can trust simplify this comparison.
    
    Signed-off-by: Vincent Donnefort <vincent.donnefort@xxxxxxx>
    Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 45f3416988f1a..2c003d193c69b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2514,8 +2514,15 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 	if (ret)
 		return ret;
 
+	/*
+	 * Resolve policy min/max to available frequencies. It ensures
+	 * no frequency resolution will neither overshoot the requested maximum
+	 * nor undershoot the requested minimum.
+	 */
 	policy->min = new_data.min;
 	policy->max = new_data.max;
+	policy->min = __resolve_freq(policy, policy->min, CPUFREQ_RELATION_L);
+	policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
 	trace_cpu_frequency_limits(policy);
 
 	policy->cached_target_freq = UINT_MAX;



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux