On 22 August 2013 04:50, Rafael J. Wysocki rjw@sisk.pl wrote:
OK, so the plan for merging this will be that we'll put 1 into linux-next and add 2 to it after a few days etc. to give people a chance to test one set of changes before going to the next one.
1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263
So perhaps we can *try* to push the above for 3.12 if it doesn't breaks stuff left and right.
Can you please resend it with all of the ACKs collected so far?
Sure..
But I believe we can reduce our work to some extent.. Probably instead of sending all again separately, we can bind them together logically..
So, I would like to divide these six patchsets into two and we can get the first one in 3.12 now..
This is how I would bind them:
Set I: CPUFreq: Introduce helper functions to remove code redundancy <132 Patches>
1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263
2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48
4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288
6. cpufreq: create & use cpufreq_generic_init() routine <This series>
Set II: CPUFreq: Make ->target lightweight() <70 Patches>
3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349
5. CPUFreq: Move freq change notifications out of drivers https://lkml.org/lkml/2013/8/15/506
What do you say? I will wait for your reply before actually spamming LKML with so many patches :)
I have updated commits with all the Acks and pushed them to my for-v3.13 branch..
-- viresh