linux-kernel - Question regarding updating intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Dec 2013 10:53:34 -0800
From:	Dirk Brandewie <dirk.brandewie@...il.com>
To:	stable@...r.kernel.org
CC:	dirk.brandewie@...il.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/