Viresh Kumar <viresh.kumar@xxxxxxxxxx> writes: > On 23 December 2013 11:25, Bjørn Mork <bjorn@xxxxxxx> wrote: >> I can confirm that it fixes the major regression. With this branch, the >> cpufreq directory is completely removed after a cancelled userspace >> hibernate (with the acpi-cpufreq problem causing failure). So it is >> possible to restore cpufreq by manually offlining and onlining non-boot >> cores. No more leftover sysfs attributes. > > Thanks for giving it a try once again :) > >> But there is still a minor regression compared to the old (v3.11) >> behaviour: Previously the cpufreq functionality would be automatically >> restored by any completed hibernate or suspend cycle, since it would >> effectively do the CPU offline/online. This automatix fixup won't happen >> with the current pm-cpufreq branch. > > I didn't understood it completely, sorry :) > > As far as I can see from 3.11 code we simply used to fail with any failure > resulting with a call to ->init() or some other call.. > > And so cpufreq wouldn't have added any directories at all in that case. > And so I think we still required an offline/online sequence to guarantee > things.. That's correct. The immediate result of the failure is exactly the same. The difference is that a subsequent resume would restore the cpufreq device whether it existed or not. That made a complete suspend/resume fix up any missing cpufreq device, e.g. one that was removed by a previous error. One effect of saving state on suspend is that a missing device isn't added on resume. You can of course see that as a feature. But to me it's a regression, because: - it didn't use to work that way, and - the addition of missing devices on resume is always wanted AFAICS. Bjørn -- 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
