Question regarding updating intel_pstate driver in stable

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

Then there's not much we can do, right? Why do you want to go against the well-known rules we have been following for the past 8+ years? What makes this hardware so "special" in that regard (hint, everyone thinks that _their_ hardware/driver is "special", and they are, just like everyone else.)

There are projects like LTSI that can take patches that are beyond the stable kernel rules, and some of the above listed projects are using LTSI for their kernels, so perhaps that might be the better solution here?

Do you really need all of those changes for the 3.10-stable kernel tree? (hint, I don't think so...)

How about distilling it down to a specific set of commits that you feel is needed. Some of the above patches could go into a stable kernel tree just fine, as they do follow the "rules", but others can't, as you point out.

What do you mean by this?

thanks,

greg k-h