From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3rNzBZ0g4XzDq5v for ; Tue, 7 Jun 2016 14:30:14 +1000 (AEST) Received: by mail-pf0-f181.google.com with SMTP id c2so899763pfa.2 for ; Mon, 06 Jun 2016 21:30:13 -0700 (PDT) Date: Tue, 7 Jun 2016 09:58:07 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Steve Muckle , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Linaro Kernel Mailman List , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , "linuxppc-dev@lists.ozlabs.org" , Dmitry Eremin-Solenikov , Krzysztof Kozlowski , Kukjin Kim , Steven Miao Subject: Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order Message-ID: <20160607042807.GC21466@vireshk-i7> References: <20160603234854.GF14579@graphite.smuckle.net> <20160606035231.GZ16176@vireshk-i7> <1649758.V7uyzAJShK@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06-06-16, 23:56, Rafael J. Wysocki wrote: > Since you are adding new code, you can write it so it doesn't do > unnecessary checks from the start. Hmm, I will do all that in this series only now. > While at it, the "if ((freq < policy->min) || (freq > policy->max))" > checks in cpufreq_find_index_l() and cpufreq_find_index_h() don't look > good to me, because they very well may cause those function to return > -EINVAL even when there's a valid table and that may cause > acpi_cpufreq_fast_switch() to do bad things. Hmm. So, the checks are for sure required here, otherwise we may end up returning a frequency which we aren't allowed to. Also note that 'freq' here isn't the target-freq, but the entry in the freq-table. This routine should be returning a valid freq within the ranges specified by policy->min/max. Also note that these routines shall *never* return -EINVAL, otherwise it is mostly a bug we are hitting. We have enough checks in place to make sure that there is at least one valid entry in the freq-table which is >= policy->min and <= policy->max. I will take care of rest of the comments though. Thanks. -- viresh