Hi, I noticed in the following changeset, the cpufreq_driver->resume call semantics looked a little odd: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]
Since acpi_cpufreq_resume and speedstep_resume appear to return 0 upon success, it seems like the attached patch is what the desired behavior would be. Otherwise, cpufreq_resume() always prints an error and exits early if using a cpufreq_driver that supports resume. -- Andres Salomon <[EMAIL PROTECTED]>
--- orig/drivers/cpufreq/cpufreq.c 2005-01-31 01:04:17.503452072 -0500
+++ mod/drivers/cpufreq/cpufreq.c 2005-01-31 01:05:15.992560376 -0500
@@ -900,9 +900,11 @@
if (cpufreq_driver->resume) {
ret = cpufreq_driver->resume(cpu_policy);
- printk(KERN_ERR "cpufreq: resume failed in ->resume step on CPU %u\n", cpu_policy->cpu);
- cpufreq_cpu_put(cpu_policy);
- return (ret);
+ if (ret) {
+ printk(KERN_ERR "cpufreq: resume failed in ->resume step on CPU %u\n", cpu_policy->cpu);
+ cpufreq_cpu_put(cpu_policy);
+ return (ret);
+ }
}
if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
signature.asc
Description: This is a digitally signed message part
