On 22 August 2013 04:50, Rafael J. Wysocki <rjw@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
