Linus picked up a bunch of the cpufreq patches I had pending today. Nothing really amazing. Several of them that I had initially queued up for this window got dropped due to regressions, or other forms of failure. Andrew beat me up a little earlier this week for merging a diff that was untested (it spat out an easily-fixed compilation warning), so I spent some time rejigging my merge scripts.

Now, before I merge patches, they have to survive a modular and an allyesconfig build on both x86 and x86-64, and also be clean of checkpatch warnings.

I fear that the initial pain barrier of getting submitters to conform with this may involve lots of hair-tearing, but hopefully it'll pay off in the long run. (One problem we've had with cpufreq submitters in the past is that when asked to resubmit with (for eg) damaged white-space fixed up, the submitters never resubmitted, requiring me to fix it up myself).

cpufreq also seems to be not getting so much attention these days. For sure there's still a bunch of work that needs doing on it, but there's probably 2-3 regular hackers posting patches, and an occasional handful of janitorial hacks sent once per merge window. My own contributions to the code have dropped off somewhat over the last year too, which is something I hope to address soon.

Another problem seems to be that cpufreq is frequently being fingered as responsible for bugs in the last few kernel versions, even when nothing has changed in the code in question. Given the extensive reworking the timer code has undergone in the last few months, I suspect some of the oddball bugs may be a bad interaction, but tracking down such bugs is something of a nightmare. Some drivers are also getting increasingly dependant upon the ACPI doing the right thing. A regression in the interpretation of an ACPI table means a broken cpufreq driver, yet it's not always obvious what is going on.