Question regarding updating intel_pstate driver in stable

Question regarding updating intel_pstate driver in stable

[Dirk Brandewie]

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

Re: Question regarding updating intel_pstate driver in stable

[Greg KH]

On Tue, Dec 17, 2013 at 10:53:34AM -0800, Dirk Brandewie wrote:
> 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.

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.)

> 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.

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?

> 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

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.

> 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.

What do you mean by this?

thanks,

greg k-h