Hi All,
I would like to see what is required to update intel_pstate in the stable
trees. Some of the patches do NOT meet the all the rules in
stable_kernel_rules.txt. v3.10.xx with intel_pstate is being used by multiple
projects at Intel that support the Baytrail and Haswell platforms. I assume
this will be case for projects outside of Intel as well. Baytrail support
came into v3.13.x and has the patch that falls outside of the stable rules.
016c815 intel_pstate: Refactor driver to support CPUs with different MSR layouts
Unfortunately the Baytrail group decided not to follow the lead of the core
group on enumerating and selecting P states which required refactoring the
driver to add support.
I would like to update all the stable tree to include the bugfixes up to
v3.12 and add Baytrail support. All of the changes are under active test on
Haswell/Baytrail with v3.10.xx and v3.13-rcX with Android, ChromeOS, Fedora
and Ubuntu.
The complete list of changes:
git log --oneline stable/linux-3.10.y..v3.13-rc4 --no-merges
drivers/cpufreq/intel_pstate.c
fbbcdc0 intel_pstate: skip the driver if ACPI has power mgmt option
e0a261a cpufreq/intel_pstate: Add static declarations to internal functions
19e77c2 intel_pstate: Add Baytrail support
016c815 intel_pstate: Refactor driver to support CPUs with different MSR layouts
7244cb6 intel_pstate: Correct calculation of min pstate value
d253d2a intel_pstate: Improve accuracy by not truncating until final result
09c87e2 intel_pstate: Fix type mismatch warning
52e0a50 cpufreq / intel_pstate: Fix max_perf_pct on resume
be49e34 cpufreq: add new routine cpufreq_verify_within_cpu_limits()
1ccf7a1 intel_pstate: fix no_turbo
6cdcdb7 intel_pstate: Add Haswell CPU models
adc97d6 cpufreq: Drop the owner field from struct cpufreq_driver
2134ed4 cpufreq / intel_pstate: Change to scale off of max P-state
2760984 cpufreq: delete __cpuinit usage from all cpufreq files
Changes
adc97d6 cpufreq: Drop the owner field from struct cpufreq_driver
be49e34 cpufreq: add new routine cpufreq_verify_within_cpu_limits()
Will be not carried back beyond the point where they entered mainline since they
are cleanup patches from the cpufreq core.
Is reasonable/possible?
If so what is the correct way to deliver patches? Patchset per stable tree.
--Dirk
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html