From patchwork Thu Jul 10 05:19:01 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 33371 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ig0-f200.google.com (mail-ig0-f200.google.com [209.85.213.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 13B1D203F4 for ; Thu, 10 Jul 2014 05:20:39 +0000 (UTC) Received: by mail-ig0-f200.google.com with SMTP id hn18sf8726277igb.7 for ; Wed, 09 Jul 2014 22:20:38 -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:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=8sWS4R7LMXEvFNhHLq8ZBbHpL17V1MPsyGU2YQuxhNY=; b=GLq9NHaFabTzwoxT+CAbMkGSYu/G3GUZg9h0PdCpMAY/G6F9KRZOzJhouAwhrJYdEt Kl+elzKIO9QIfajyNlD13IcBiDqkqnb7l8Kc1iF5HKwi3zUCItg8eO6T2xz+Pres8gck +IwHQDYo1h1VwEFljwRA+g88UUwV+uIPBjPRJQfetL9mo6yu6HjzPwYNsWHhrzRAcoqn aCfx13ujRxkwnyfQhwKJXL21p7ZN0LozRIPUDAOqM0BT2xlhJkUziFf3WtpZ3lS5+bEj o9qvLPF7g/VLyfxsRpWX0fYAKsYktMYSctZULEmDr2NdXIuCSs5wEe+5hzdG9vAthIY2 6c8Q== X-Gm-Message-State: ALoCoQkA4YY9lJbK8O5fu0UljNKiA8a9F+h8AYMOmqpQ5Df6AV2L1OiZ25n4zgrDKyNcZi39j1BB X-Received: by 10.42.15.197 with SMTP id m5mr22123555ica.31.1404969638590; Wed, 09 Jul 2014 22:20:38 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.101.205 with SMTP id u71ls2790104qge.52.gmail; Wed, 09 Jul 2014 22:20:38 -0700 (PDT) X-Received: by 10.52.72.39 with SMTP id a7mr36286543vdv.13.1404969638463; Wed, 09 Jul 2014 22:20:38 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx.google.com with ESMTPS id xo6si22547853veb.19.2014.07.09.22.20.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 22:20:38 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.182 as permitted sender) client-ip=209.85.220.182; Received: by mail-vc0-f182.google.com with SMTP id il7so9760240vcb.27 for ; Wed, 09 Jul 2014 22:20:38 -0700 (PDT) X-Received: by 10.52.84.162 with SMTP id a2mr36572853vdz.23.1404969638358; Wed, 09 Jul 2014 22:20:38 -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 tc5csp104571vcb; Wed, 9 Jul 2014 22:20:37 -0700 (PDT) X-Received: by 10.70.36.135 with SMTP id q7mr772364pdj.79.1404969637462; Wed, 09 Jul 2014 22:20:37 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ka6si47631194pbc.153.2014.07.09.22.20.36; Wed, 09 Jul 2014 22:20:36 -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 S1750804AbaGJFUf (ORCPT + 14 others); Thu, 10 Jul 2014 01:20:35 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:49170 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbaGJFUe (ORCPT ); Thu, 10 Jul 2014 01:20:34 -0400 Received: by mail-pa0-f52.google.com with SMTP id eu11so10312944pac.25 for ; Wed, 09 Jul 2014 22:20:34 -0700 (PDT) X-Received: by 10.66.234.65 with SMTP id uc1mr1080813pac.123.1404969634050; Wed, 09 Jul 2014 22:20:34 -0700 (PDT) Received: from localhost ([122.167.123.210]) by mx.google.com with ESMTPSA id x15sm880786pbt.10.2014.07.09.22.20.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 09 Jul 2014 22:20:33 -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 Subject: [PATCH] cpufreq: move policy kobj to policy->cpu at resume Date: Thu, 10 Jul 2014 10:49:01 +0530 Message-Id: <3b19a388891fe997c6c7bc14463453c27312edfa.1404968266.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.0.0.rc2 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.182 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 offlining CPUs from 1 to 3. When CPU2 is remove, policy->kobj would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its kobj. 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 wasn't moved to CPU2. We wouldn't create a link for CPU2, but would try that while bringing CPU3 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. Fixes: ("42f921a cpufreq: remove sysfs files for CPUs which failed to come back after resume") Cc: Stable # 3.13+ Reported-by: Bu Yitian Reported-by: Saravana Kannan Signed-off-by: Viresh Kumar Tested-by: Bu Yitian Reviewed-by: Srivatsa S. Bhat --- Hi Rafael, This is for 3.16 release, please take it once Yitian/Saravana test this out. @Yitian/Saravana: Sorry of overlooking this when both of you reported this first. I (and Srivatsa as well) was damn sure that this scenario is taken into account in current code and a close look proved that wrong. I couldn't test it out, can any of you please see if it fixes things for you? 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));