From patchwork Fri Jun 3 05:11:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 69215 Delivered-To: patch@linaro.org Received: by 10.140.106.246 with SMTP id e109csp86007qgf; Thu, 2 Jun 2016 22:11:52 -0700 (PDT) X-Received: by 10.98.81.3 with SMTP id f3mr3477553pfb.132.1464930712108; Thu, 02 Jun 2016 22:11:52 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 199si5158365pfz.17.2016.06.02.22.11.51; Thu, 02 Jun 2016 22:11:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750923AbcFCFLu (ORCPT + 14 others); Fri, 3 Jun 2016 01:11:50 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:34902 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750726AbcFCFLt (ORCPT ); Fri, 3 Jun 2016 01:11:49 -0400 Received: by mail-pa0-f49.google.com with SMTP id xk1so11232232pac.2 for ; Thu, 02 Jun 2016 22:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=9Cg3EpEnpwvmOTM2pVWOf5WLSGxwYEECoUw7A8IbEFk=; b=F5igaxuQcopj75mHdQ22z1vkzly35hy2RSYaiN3P2EtTYGy6HQQBL1u7OzkCdiPILp ciOosUAhyJNcCNm/uDN9atH7dlA/WCoc8m4P67zbRNSJG1c4wfYhOyf0sTITNiwNCywX bDBUta5aauGeTB9niqBSXJTFs9Xqud6vZnbbs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9Cg3EpEnpwvmOTM2pVWOf5WLSGxwYEECoUw7A8IbEFk=; b=CByRuud2UcLF9+sdUXxzVIFt5WOGK2dFd9df4b5Lc7GUiH4jJrFruYCuLQtKxDljff VzyKiGOHoEol00qHUW30Dn2kxiO2gbePnSRJhULJlUBOoPX0FiyacAjcTtjjAx0S2Gp/ Ezjr5OVln5d3UOTyt2+T+oEyB6vEGYG9g7cW+Nx1V+W3kAE8K0JyKrV+8Nt1CGuxfb2y hF7lxRapXZpFbg7cSUmkUcsEviO1QpPeFeXVtL9v7DY1D14MhIOQ5fcLkbTj5IbQq6Es rgZnXFup/L1YcfUhPGwPDqpRM6Tna4OzPC5sEiE0EfG7n4kLlth/UJvw208UGvJyvRlE LlBw== X-Gm-Message-State: ALyK8tK/Lz33dUbjaPVBT241HPOTw5iwdcww9jNZMlJCmnwEDJ+IR1zIO7rKQtc1nyiNRti+ X-Received: by 10.66.66.42 with SMTP id c10mr2561412pat.119.1464930708585; Thu, 02 Jun 2016 22:11:48 -0700 (PDT) Received: from localhost ([122.167.17.193]) by smtp.gmail.com with ESMTPSA id g82sm4634893pfj.22.2016.06.02.22.11.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2016 22:11:47 -0700 (PDT) Date: Fri, 3 Jun 2016 10:41:45 +0530 From: Viresh Kumar To: Javi Merino Cc: Rafael Wysocki , Amit Daniel Kachhap , Zhang Rui , Eduardo Valentin , Linaro Kernel Mailman List , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List Subject: Re: [PATCH V2 2/6] cpufreq: Remove cpufreq_frequency_get_table() Message-ID: <20160603051145.GK16176@vireshk-i7> References: <13d43ddfe208a9b387fe0fd247de069ba0332308.1464876229.git.viresh.kumar@linaro.org> <20160602145903.GA2966@e104805> <20160602180250.GC2966@e104805> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160602180250.GC2966@e104805> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 02-06-16, 19:02, Javi Merino wrote: > On Thu, Jun 02, 2016 at 09:06:26PM +0530, Viresh Kumar wrote: > > On 2 June 2016 at 20:29, Javi Merino wrote: > > > In 5a31d594a973 ("cpufreq: Allow freq_table to be obtained for offline > > > CPUs") you did the opposite: don't use cpufreq_cpu_get_raw() because > > > it won't give you the policy of a cpu that is offline. Now you are > > > arguing that we should go back to cpufreq_cpu_get() which implicitly > > > calls cpufreq_cpu_get_raw(). Won't we hit the same issue that > > > 5a31d594a973 was trying to prevent: that we can't get a freq_table for > > > a cpu that is offline? > > > > Yes, that should be fixed. Thanks for letting me know about it :) > > Ok, that was my only nit. Other than that, it looks good to me. For cpu_cooling.c > > Acked-by: Javi Merino Thanks, I will be adding this to the original patch. This will also make this problem clear, otherwise it was just hidden in the function call which was really easy to miss, as I missed it as well :( -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index 63f760869651..4d678cfc81b1 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -792,10 +792,12 @@ __cpufreq_cooling_register(struct device_node *np, struct cpufreq_cooling_device *cpufreq_dev; char dev_name[THERMAL_NAME_LENGTH]; struct cpufreq_frequency_table *pos, *table; + struct cpumask temp_mask; unsigned int freq, i, num_cpus; int ret; - policy = cpufreq_cpu_get(cpumask_first(clip_cpus)); + cpumask_and(&temp_mask, clip_cpus, cpu_online_mask); + policy = cpufreq_cpu_get(cpumask_first(&temp_mask)); if (!policy) { pr_debug("%s: CPUFreq policy not found\n", __func__); return ERR_PTR(-EPROBE_DEFER);