From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Srivatsa S. Bhat" Subject: Re: [PATCH 1/8] cpufreq: Revert commit a66b2e to fix cpufreq regression during suspend/resume Date: Mon, 15 Jul 2013 11:48:04 +0530 Message-ID: <51E3941C.2010101@linux.vnet.ibm.com> References: <20130711221419.547.69781.stgit@srivatsabhat.in.ibm.com> <20130711221527.547.46447.stgit@srivatsabhat.in.ibm.com> <1373719585.1359.3.camel@x61.thuisdomein> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from e23smtp06.au.ibm.com ([202.81.31.148]:38131 "EHLO e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753973Ab3GOGVk (ORCPT ); Mon, 15 Jul 2013 02:21:40 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 15 Jul 2013 16:13:59 +1000 In-Reply-To: <1373719585.1359.3.camel@x61.thuisdomein> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Paul Bolle Cc: Viresh Kumar , rjw@sisk.pl, toralf.foerster@gmx.de, robert.jarzmik@intel.com, durgadoss.r@intel.com, tianyu.lan@intel.com, lantianyu1986@gmail.com, dirk.brandewie@gmail.com, stern@rowland.harvard.edu, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org On 07/13/2013 06:16 PM, Paul Bolle wrote: > On Fri, 2013-07-12 at 12:48 +0530, Viresh Kumar wrote: >> On 12 July 2013 03:45, Srivatsa S. Bhat >> 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: stable@vger.kernel.org >>> Signed-off-by: Srivatsa S. Bhat >>> --- >>> >>> drivers/cpufreq/cpufreq.c | 4 +++- >>> drivers/cpufreq/cpufreq_stats.c | 6 ++---- >>> 2 files changed, 5 insertions(+), 5 deletions(-) >> >> Acked-by: Viresh Kumar > > This seems to fix the "core stuck at some frequency after resume" issue > I ran into since v3.10. So: > > Tested-by: Paul Bolle > Thanks Paul! Regards, Srivatsa S. Bhat