From patchwork Sat Nov 21 03:34:59 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 57095 Delivered-To: patch@linaro.org Received: by 10.112.155.196 with SMTP id vy4csp237535lbb; Fri, 20 Nov 2015 19:35:13 -0800 (PST) X-Received: by 10.68.134.137 with SMTP id pk9mr23273925pbb.88.1448076913266; Fri, 20 Nov 2015 19:35:13 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id vz3si3334514pab.93.2015.11.20.19.35.12; Fri, 20 Nov 2015 19:35:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dkim=neutral (body hash did not verify) header.i=@linaro-org.20150623.gappssmtp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760251AbbKUDfJ (ORCPT + 28 others); Fri, 20 Nov 2015 22:35:09 -0500 Received: from mail-pa0-f45.google.com ([209.85.220.45]:34937 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759630AbbKUDfH (ORCPT ); Fri, 20 Nov 2015 22:35:07 -0500 Received: by pacej9 with SMTP id ej9so134565063pac.2 for ; Fri, 20 Nov 2015 19:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=izLBQ2OUHqAwoI6RZGvqryImPBwQD6awYG4g74kOYEs=; b=Ru51sFx9CTIxlKSUPDh2dCnoLE2MyqZHuvLPPQvQ+yTgkv99dgfLSuiW7vbwLwTLPG jpiuM5yu6qUtR9Msh+hndQ+G8r2rIxfCIzE5hyabzSLTmu3ldHEU/JL4Z0q1xl8dCWkW frgwPrOhoR8rWvyrVrsqk2Z+Hqrsou89HWAR3JGZrVkg6oJSAaDCw+vIEueW2KtjGCbs s/as3arqLptSxvAAK107uJeiFnhrn9W8QN3/bO97bdTVSmUHbrqUMm0+ETMO3OrAaCdj 5Nh29T3vwd+6cZvpHxvR31t7gn54D7SpUcjb09PDP0deQ5muPngEaUDDgr4NgI39UzhU 1O2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=izLBQ2OUHqAwoI6RZGvqryImPBwQD6awYG4g74kOYEs=; b=VDOhofnO0M1fge/+iHYs6bPr1ANTUFqXiQnc4Wlu7qftPNMueHniS3eABBbsBtzN+a G3dP3EB1fU37ivTQxOIeQzeHM6Dr3gDFSaSfIyaZ9g9DoKicA9Y28vAH63W4TPCRSQrW 9r0KOuS4Df9NyW9CYCih4gDK1TOaGbzOjU7vCAz69FhwSMsh685M4nZ8pC/SuSpsCdDm XNSRYjlB4vP8dAKeGpo3ZXYxZgIlp2B+89Y1HPLaEzi7Vhau/IMhjfI1dIevnz8rscRF wQZhKY3mqcrubX4zoRlUwBBQyq3+A/ri/HRr0biYI6ZlGWmTANRwQmZ/Lo5mki9WoxbR zTSw== X-Gm-Message-State: ALoCoQkfW9laFworgXjMlQ86IsY7JMxFdTWG7hf3srYagqSrb8CimC38PAlkAzXW2HV6OeTNzLIn X-Received: by 10.98.7.193 with SMTP id 62mr3233655pfh.22.1448076906852; Fri, 20 Nov 2015 19:35:06 -0800 (PST) Received: from localhost ([122.167.29.19]) by smtp.gmail.com with ESMTPSA id 9sm1052893pfn.51.2015.11.20.19.35.05 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 20 Nov 2015 19:35:06 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , srinivas.pandruvada@linux.intel.com Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, Viresh Kumar , linux-kernel@vger.kernel.org (open list) Subject: [PATCH] cpufreq: Always remove sysfs cpuX/cpufreq link on ->remove_dev() Date: Sat, 21 Nov 2015 09:04:59 +0530 Message-Id: <1d6d4fe9794e4547e0a899141e67313e7d3f453a.1448076816.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.6.2.198.g614a2ac In-Reply-To: <1448074212.3450.4.camel@linux.intel.com> References: <1448074212.3450.4.camel@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Subsys interface's ->remove_dev() is called when the cpufreq driver is unregistering or the CPU is getting physically removed. We keep removing the cpuX/cpufreq link for all CPUs except the last one, which is a mistake as all CPUs contain a link now. Because of this, one CPU from each policy will still contain a link (to an already removed policyX directory), after the cpufreq driver is unregistered. Fix that by removing the link first and then only see if the policy is required to be freed. That will make sure that no links are left out. Fixes: 96bdda61f58b ("cpufreq: create cpu/cpufreq/policyX directories") Reported-by: Srinivas Pandruvada Signed-off-by: Viresh Kumar --- @Srinivas: This should fix it for you. drivers/cpufreq/cpufreq.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.6.2.198.g614a2ac -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 7c48e7316d91..163ba0503ddf 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1401,13 +1401,12 @@ static void cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) } cpumask_clear_cpu(cpu, policy->real_cpus); + remove_cpu_dev_symlink(policy, cpu); if (cpumask_empty(policy->real_cpus)) { cpufreq_policy_free(policy, true); return; } - - remove_cpu_dev_symlink(policy, cpu); } static void handle_update(struct work_struct *work)