From patchwork Thu Jul 17 05:18:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 33768 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ig0-f197.google.com (mail-ig0-f197.google.com [209.85.213.197]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 57CA2201F1 for ; Thu, 17 Jul 2014 05:19:58 +0000 (UTC) Received: by mail-ig0-f197.google.com with SMTP id r2sf7127546igi.0 for ; Wed, 16 Jul 2014 22:19:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:in-reply-to:references :sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=cfc1/VYG469g+PjfKNkERcQMd/MLmPMeqxmRFM9iIVw=; b=Cr3HEA55OaCfYYxaLqh+Y/r6qfL1p6SDhHkF8NtmTRAsZIoS0S3w43CQ6cJMT/T4Ko 947rKk9cLSWHvWV85kOgbe1/Mo6p8ASn7mX8a1PLrzoBpxh8fEuG1keAb9EZbhjZd4OQ uXrfy0JLuGkL2J+LwJIK/o2GrPgfVDdk0gV2QoosED3rYir2dCzWrqBcAo/n8UqPXnrD 7DY+TdWzLi/mdkK0x4xSoQoawEjRQ95R2JdX59PGDo+wTktXmNXCLGZgdXhNMozfJlA0 NY7Seq99kpmcF9emsLdHA1j+EURVXkBuK9N0kYGpeiiMp5btmPIu4P926mUIVJ7bS0NH wf7g== X-Gm-Message-State: ALoCoQl7+2UrA81P+DiB1xAedBrNC9VdjbMCehdP90dwVAA0CbfYCAaqggR3lRZS2V/JemgwEzl7 X-Received: by 10.43.149.193 with SMTP id kl1mr17889148icc.5.1405574397679; Wed, 16 Jul 2014 22:19:57 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.29.55 with SMTP id a52ls595580qga.14.gmail; Wed, 16 Jul 2014 22:19:57 -0700 (PDT) X-Received: by 10.52.154.106 with SMTP id vn10mr16424576vdb.36.1405574397579; Wed, 16 Jul 2014 22:19:57 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx.google.com with ESMTPS id bl6si1325360vdd.61.2014.07.16.22.19.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 22:19:57 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; Received: by mail-vc0-f174.google.com with SMTP id la4so3509438vcb.5 for ; Wed, 16 Jul 2014 22:19:57 -0700 (PDT) X-Received: by 10.52.244.81 with SMTP id xe17mr29922724vdc.24.1405574397504; Wed, 16 Jul 2014 22:19:57 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.37.5 with SMTP id tc5csp5959vcb; Wed, 16 Jul 2014 22:19:56 -0700 (PDT) X-Received: by 10.66.142.232 with SMTP id rz8mr33859873pab.80.1405574395886; Wed, 16 Jul 2014 22:19:55 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id mu3si623908pdb.77.2014.07.16.22.19.55; Wed, 16 Jul 2014 22:19:55 -0700 (PDT) Received-SPF: none (google.com: linux-pm-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753211AbaGQFTx (ORCPT + 15 others); Thu, 17 Jul 2014 01:19:53 -0400 Received: from mail-qa0-f45.google.com ([209.85.216.45]:44917 "EHLO mail-qa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752635AbaGQFTw (ORCPT ); Thu, 17 Jul 2014 01:19:52 -0400 Received: by mail-qa0-f45.google.com with SMTP id cm18so1491882qab.18 for ; Wed, 16 Jul 2014 22:19:52 -0700 (PDT) X-Received: by 10.140.50.50 with SMTP id r47mr53820106qga.96.1405574392265; Wed, 16 Jul 2014 22:19:52 -0700 (PDT) Received: from localhost (ec2-23-23-178-99.compute-1.amazonaws.com. [23.23.178.99]) by mx.google.com with ESMTPSA id s9sm1670696qge.42.2014.07.16.22.19.47 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 16 Jul 2014 22:19:51 -0700 (PDT) From: Viresh Kumar To: rjw@rjwysocki.net Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, arvind.chauhan@arm.com, srivatsa@mit.edu, skannan@codeaurora.org, ybu@qti.qualcomm.com, Viresh Kumar , stable@vger.kernel.org Subject: [PATCH V1 Resend 1/4] cpufreq: move policy kobj to policy->cpu at resume Date: Thu, 17 Jul 2014 10:48:25 +0530 Message-Id: <568e1bd8a6e3e5eff48e84a0d142464a35c09694.1405573982.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.0.0.rc2 In-Reply-To: References: In-Reply-To: References: Sender: linux-pm-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.174 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , This is only relevant to implementations with multiple clusters, where clusters have separate clock lines but all CPUs within a cluster share it. Consider a dual cluster platform with 2 cores per cluster. During suspend we start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its kobj as we want to retain permissions/values/etc. Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev(). We will recover the old policy and update policy->cpu from 3 to 2 from update_policy_cpu(). But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a link for CPU2, but would try that for CPU3 while bringing it online. Which will report errors as CPU3 already has kobj assigned to it. This bug got introduced with commit 42f921a, which overlooked this scenario. To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here only for the first CPU of a non-boot cluster. And we can't recover from this situation, if kobject_move() fails. Fixes: ("42f921a cpufreq: remove sysfs files for CPUs which failed to come back after resume") Cc: stable@vger.kernel.org # 3.13+ Reported-by: Bu Yitian Reported-by: Saravana Kannan Tested-by: Bu Yitian Reviewed-by: Srivatsa S. Bhat Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 62259d2..6f02485 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1153,10 +1153,12 @@ static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) * the creation of a brand new one. So we need to perform this update * by invoking update_policy_cpu(). */ - if (recover_policy && cpu != policy->cpu) + if (recover_policy && cpu != policy->cpu) { update_policy_cpu(policy, cpu); - else + WARN_ON(kobject_move(&policy->kobj, &dev->kobj)); + } else { policy->cpu = cpu; + } cpumask_copy(policy->cpus, cpumask_of(cpu));