On 12 July 2013 03:45, Srivatsa S. Bhat <srivatsa.b...@linux.vnet.ibm.com> wrote: > commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has > unfortunately caused several things in the cpufreq subsystem to break subtly > after a suspend/resume cycle. > > The intention of that patch was to retain the file permissions of the > cpufreq related sysfs files across suspend/resume. To achieve that, the commit > completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() > during suspend/resume transitions. But the problem is that those functions > do 2 kinds of things: > 1. Low-level initialization/tear-down that are critical to the correct > functioning of cpufreq-core. > 2. Kobject and sysfs related initialization/teardown. > > Ideally we should have reorganized the code to cleanly separate these two > responsibilities, and skipped only the sysfs related parts during > suspend/resume. Since we skipped the entire callbacks instead (which also > included some CPU and cpufreq-specific critical components), cpufreq > subsystem started behaving erratically after suspend/resume. > > So revert the commit to fix the regression. We'll revisit and address the > original goal of that commit separately, since it involves quite a bit of > careful code reorganization and appears to be non-trivial. > > (While reverting the commit, note that another commit f51e1eb "cpufreq: > Fix cpufreq regression after suspend/resume" already reverted part of the > original set of changes. So revert only the remaining ones). > > Cc: sta...@vger.kernel.org > Signed-off-by: Srivatsa S. Bhat <srivatsa.b...@linux.vnet.ibm.com> > --- > > drivers/cpufreq/cpufreq.c | 4 +++- > drivers/cpufreq/cpufreq_stats.c | 6 ++---- > 2 files changed, 5 insertions(+), 5 deletions(-)
Acked-by: Viresh Kumar <viresh.ku...@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
