From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751671AbeEPW5j (ORCPT ); Wed, 16 May 2018 18:57:39 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:36423 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395AbeEPW5h (ORCPT ); Wed, 16 May 2018 18:57:37 -0400 X-Google-Smtp-Source: AB8JxZpT9gPE3XhT3LDj3cVGjr7TawXMu/KrHxH5ORMAsbBO4awkQycS9De3p3MNTGqDulbYvzYFlg== From: Matthias Kaehlcke To: MyungJoo Ham , Kyungmin Park , Chanwoo Choi Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Brian Norris , Douglas Anderson , Matthias Kaehlcke Subject: [PATCH] PM / devfreq: Init user limits from OPP limits, not viceversa Date: Wed, 16 May 2018 15:57:09 -0700 Message-Id: <20180516225709.153138-1-mka@chromium.org> X-Mailer: git-send-email 2.17.0.441.gb46fe60e1d-goog Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") introduced the initialization of the user limits min/max_freq from the lowest/highest available OPPs. Later commit f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") added scaling_min/max_freq, which actually represent the frequencies of the lowest/highest available OPP. scaling_min/ max_freq are initialized with the values from min/max_freq, which is totally correct in the context, but a bit awkward to read. Swap the initialization and assign scaling_min/max_freq with the OPP freqs and then the user limts min/max_freq with scaling_min/ max_freq. Needless to say that this change is a NOP, intended to improve readability. Signed-off-by: Matthias Kaehlcke --- Additional context: I'm considering to introduce the concept of a devfreq policy, which would probably move min/max_freq inside of a struct policy, this would make the initialization even more awkward to read. If this moves forward I might also propose to rename scaling_min/max_freq to something like min/max_opp_freq to avoid confusion with the frequencies in the policy (cpufreq uses scaling_min/max_freq for the sysfs attributes of the policy limits). drivers/devfreq/devfreq.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index fe2af6aa88fc..0057ef5b0a98 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -604,21 +604,21 @@ struct devfreq *devfreq_add_device(struct device *dev, mutex_lock(&devfreq->lock); } - devfreq->min_freq = find_available_min_freq(devfreq); - if (!devfreq->min_freq) { + devfreq->scaling_min_freq = find_available_min_freq(devfreq); + if (!devfreq->scaling_min_freq) { mutex_unlock(&devfreq->lock); err = -EINVAL; goto err_dev; } - devfreq->scaling_min_freq = devfreq->min_freq; + devfreq->min_freq = devfreq->scaling_min_freq; - devfreq->max_freq = find_available_max_freq(devfreq); - if (!devfreq->max_freq) { + devfreq->scaling_max_freq = find_available_max_freq(devfreq); + if (!devfreq->scaling_max_freq) { mutex_unlock(&devfreq->lock); err = -EINVAL; goto err_dev; } - devfreq->scaling_max_freq = devfreq->max_freq; + devfreq->max_freq = devfreq->scaling_max_freq; dev_set_name(&devfreq->dev, "devfreq%d", atomic_inc_return(&devfreq_no)); -- 2.17.0.441.gb46fe60e1d-goog