On 5 March 2014 08:37, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > So, previously the driver's ->suspend callback was executed with interrupts off > and it was only executed for the boot CPU. > > Now, it is going to be executed for all CPUs and with interrupts on. Its not called for all CPUs but once for each instance of 'policy'. > This sounds potentially dangerous, so did you check all drivers supplying > ->suspend if they are fine with that? > > And same for ->resume, of course. Completely agree with you on that. I had similar doubts when I started earlier. And then grep'd for suspend/resume in drivers/cpufreq and this is what I found: drivers/cpufreq/acpi-cpufreq.c: Only have resume implemented and is unaffected with new code. drivers/cpufreq/pmac32-cpufreq.c: This is always UP and so no issues. drivers/cpufreq/s3c24xx-cpufreq.c: There is only one policy and so would be called only once. drivers/cpufreq/speedstep-smi.c: Only has resume implemented and it looks to be harmless again.. So, I think yes, we shouldn't end up breaking any stuff here. Fingers crossed :) Otherwise as well, I am not going on leaves or something else in coming weeks and would be there to fix any issues that might come in. But I am still hopeful of not breaking any existing stuff. -- 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
