Question regarding updating intel_pstate driver in stable

[Dirk Brandewie <dirk.brandewie@gmail.com>]

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