From patchwork Mon Nov 17 08:08:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 40879 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wg0-f70.google.com (mail-wg0-f70.google.com [74.125.82.70]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id D1DF521F5F for ; Mon, 17 Nov 2014 08:08:33 +0000 (UTC) Received: by mail-wg0-f70.google.com with SMTP id x13sf11027386wgg.5 for ; Mon, 17 Nov 2014 00:08:33 -0800 (PST) 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=WQNEV+OZAyt2lRHj9wOU5tY8qyTTyB5eJkUPSpgnMMI=; b=d+3XyryceARCKMyV+43ep1tU9rzhXCyyrWcdNIZ3BSchyVxbNgRfAgrwMIkoASxu6q qi5OXmOijFOKSTxC90GhKS/vftp0qTKTaofX1FoZLlhVzTZVWWNxPxrTDQ17V4OONfLB zOIk32kW5jQh+EwhohVyXQBiBujnB6z6QD8A5jTMl61yjEP8eY08iji4WdgIzqdOswuh /7nG1l3SH8ftM0zJndBg61VRfw7Q4RFBek9cBnArbtGouugwJrFPexMJZMM4MQo+lahc +cBUSKhxeAyRm5a+vz4xM/phGjBYSYbNXhq68eSl1a+DYG609PCwQf4BEhyxN+q9wtL+ 22bw== X-Gm-Message-State: ALoCoQn0hL8ZJm8Y3gn4ML9FFbHNp2cHnFrH/MaDx6tJBlLSEQBzy9wI9seWVYhkm2n1sjawV31G X-Received: by 10.112.163.229 with SMTP id yl5mr12318lbb.23.1416211713008; Mon, 17 Nov 2014 00:08:33 -0800 (PST) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.3.170 with SMTP id d10ls59416lad.37.gmail; Mon, 17 Nov 2014 00:08:32 -0800 (PST) X-Received: by 10.112.199.131 with SMTP id jk3mr13352246lbc.45.1416211712767; Mon, 17 Nov 2014 00:08:32 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com. [209.85.215.52]) by mx.google.com with ESMTPS id jm10si20358482lbc.89.2014.11.17.00.08.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 00:08:32 -0800 (PST) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; Received: by mail-la0-f52.google.com with SMTP id pv20so17958567lab.11 for ; Mon, 17 Nov 2014 00:08:32 -0800 (PST) X-Received: by 10.112.189.10 with SMTP id ge10mr25307571lbc.23.1416211712554; Mon, 17 Nov 2014 00:08:32 -0800 (PST) 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.112.184.201 with SMTP id ew9csp1119092lbc; Mon, 17 Nov 2014 00:08:31 -0800 (PST) X-Received: by 10.66.179.16 with SMTP id dc16mr28243670pac.11.1416211710824; Mon, 17 Nov 2014 00:08:30 -0800 (PST) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1si30845293pdm.171.2014.11.17.00.08.30 for ; Mon, 17 Nov 2014 00:08:30 -0800 (PST) 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 S1751072AbaKQII3 (ORCPT + 12 others); Mon, 17 Nov 2014 03:08:29 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:43533 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751489AbaKQII2 (ORCPT ); Mon, 17 Nov 2014 03:08:28 -0500 Received: by mail-pa0-f43.google.com with SMTP id kx10so1542495pab.2 for ; Mon, 17 Nov 2014 00:08:28 -0800 (PST) X-Received: by 10.66.252.193 with SMTP id zu1mr12967pac.153.1416211708090; Mon, 17 Nov 2014 00:08:28 -0800 (PST) Received: from localhost ([122.166.94.182]) by mx.google.com with ESMTPSA id ub7sm34258122pbc.30.2014.11.17.00.08.26 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 17 Nov 2014 00:08:27 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , stefan.wahren@i2se.com Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, nm@ti.com, linux-arm-kernel@lists.infradead.org, Viresh Kumar Subject: [PATCH] opp: convert dev_warn() to dev_dbg() for duplicate OPPs Date: Mon, 17 Nov 2014 13:38:00 +0530 Message-Id: <7017fa592bdaf73c260ad001a2b7abdc8d14f08a.1416211616.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.0.3.693.g996b0fd 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.215.52 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: , Giving a warning in case we add duplicate OPPs doesn't workout that great. For example just playing with cpufreq-dt driver as a module results in this: $ modprobe cpufreq-dt $ modprobe -r cpufreq-dt $ modprobe cpufreq-dt cpu cpu0: dev_pm_opp_add: duplicate OPPs detected. Existing: freq: 261819000, volt: 1350000, enabled: 1. New: freq: 261819000, volt: 1350000, enabled: 1 cpu cpu0: dev_pm_opp_add: duplicate OPPs detected. Existing: freq: 360000000, volt: 1350000, enabled: 1. New: freq: 360000000, volt: 1350000, enabled: 1 cpu cpu0: dev_pm_opp_add: duplicate OPPs detected. Existing: freq: 392728000, volt: 1450000, enabled: 1. New: freq: 392728000, volt: 1450000, enabled: 1 cpu cpu0: dev_pm_opp_add: duplicate OPPs detected. Existing: freq: 454737000, volt: 1550000, enabled: 1. New: freq: 454737000, volt: 1550000, enabled: 1 This happens because we don't destroy OPPs (created during ->init()) while unloading modules. Now the question is: Should we destroy these OPPs? Logically kernel drivers *must* free resources they acquired. But in this particular case, the OPPs are created using a static list present in device tree. Destroying and then allocating them again isn't of much benefit. The only benefit of removing OPPs is to save some space if the driver isn't loaded again. This has its own complications. OPPs can be created either from DT (static) or platform code (dynamic). Driver should only remove static OPPs and not the dynamic ones as they are controlled from platform code. But there is no field in 'struct dev_pm_opp' which has this information to distinguish between different kind of OPPs. Because of all this, I wasn't sure if drivers should remove static OPPs during their removal. And so just fixing the reported issue by issuing a dev_dbg() instead of dev_warn(). Reported-by: Stefan Wahren Signed-off-by: Viresh Kumar --- drivers/base/power/opp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index 89ced95..490e9db 100644 --- a/drivers/base/power/opp.c +++ b/drivers/base/power/opp.c @@ -466,9 +466,9 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt) int ret = opp->available && new_opp->u_volt == opp->u_volt ? 0 : -EEXIST; - dev_warn(dev, "%s: duplicate OPPs detected. Existing: freq: %lu, volt: %lu, enabled: %d. New: freq: %lu, volt: %lu, enabled: %d\n", - __func__, opp->rate, opp->u_volt, opp->available, - new_opp->rate, new_opp->u_volt, new_opp->available); + dev_dbg(dev, "%s: duplicate OPPs detected. Existing: freq: %lu, volt: %lu, enabled: %d. New: freq: %lu, volt: %lu, enabled: %d\n", + __func__, opp->rate, opp->u_volt, opp->available, + new_opp->rate, new_opp->u_volt, new_opp->available); mutex_unlock(&dev_opp_list_lock); kfree(new_opp); return ret;