Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp302597imm; Tue, 21 Aug 2018 20:12:21 -0700 (PDT) X-Google-Smtp-Source: AA+uWPx4O44btKtKf5qUNpMi4aaamJAXZiP2xUdIRRpSgK3bZW+TXkYZq99K+o/OXOBuVEMomVJP X-Received: by 2002:a63:380d:: with SMTP id f13-v6mr49803354pga.124.1534907541855; Tue, 21 Aug 2018 20:12:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534907541; cv=none; d=google.com; s=arc-20160816; b=sJ2p4SCXe0DODf78cpj3Ir2bmmfG9WaeLyQEnCcUYgCy1cTxsPxSOtc3FS1l/s5psx Uz5Vh5mreO/t9VtcTO8a/T5LQ5ngw5Ox8raSmeVcDN9cTq5uAblEA/vf9E9Xod1j3IvU mKGRWhyYBnd5pa3LRAL/yPdD2WZ7FkJih5ppKUocy1iVVxot+C1mzJP7GUtYH0ZJqAXn fvTep/fY0Mt2Ubrg1TojRxholfRL2ITWSS7CaZBfbx47AjVZF22kTcewbnU3/hfTFrWv ePdEcz1I7Of749VeveabGgEnCSrJe6mfdHD94djvqydJC+tbbwCWkqm21/fLISiiIJXz 5LKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:dkim-signature:arc-authentication-results; bh=5x9rVUJnCe+WIJt+p1u8sgAiQ7nvI/ba9gqrGJ9wc5E=; b=LamqBcdCA3PpGer6HvmHGhzDFATo89Bfg4+SXn0nvXy230Vwqe44juvHKNl3UmPSoH zdwQgiF8/90cmAxmzJRinNb27Ijbon4o7jbcklwWza/gg3ZEv0BhkZd+xKfwJ03XIb3Z ypAp0aY59jphUfzGyyv7tCmCnmwyz8golP3DyFbHCRsfF3Ws7WrxDj+4dhg9CMW3rHzl H8BU0bXNgXjKdFKrHvJEzvPnkVDCzACC7x3mK1QtKzDlLfO0SCQBh6zG8hKAvrCdy5Yr lhh3L1VivAfbefyudPpSieLiaT3yCtacdUQg5fqd41v0TEwBGYyhiz0Y/Mo0PhiYGC7I 9Oag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=DSdDltzI; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 35-v6si576113pgo.361.2018.08.21.20.12.06; Tue, 21 Aug 2018 20:12:21 -0700 (PDT) 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; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=DSdDltzI; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728003AbeHVGdw (ORCPT + 99 others); Wed, 22 Aug 2018 02:33:52 -0400 Received: from lelv0142.ext.ti.com ([198.47.23.249]:49838 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726469AbeHVGdw (ORCPT ); Wed, 22 Aug 2018 02:33:52 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id w7M3Aqlq013761; Tue, 21 Aug 2018 22:10:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1534907452; bh=5x9rVUJnCe+WIJt+p1u8sgAiQ7nvI/ba9gqrGJ9wc5E=; h=From:To:CC:Subject:Date; b=DSdDltzIP/T+jiy2C7IPu5frhlGzM78Dt5KNpNPFqy6JKPAkEl8sCt06BRhnHPo0Q 3rw5TuwnVduNJ6ykP7tn5G2KHJBsz/UpgQyxCgMqEKXQyNcTk3nwFW3Eq9Rw4SS8Tj JGsNS0T/4pNOSwVljYJ1O6Oj+mtGNorz8HODnYIw= Received: from DLEE105.ent.ti.com (dlee105.ent.ti.com [157.170.170.35]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w7M3Aq1r003125; Tue, 21 Aug 2018 22:10:52 -0500 Received: from DLEE109.ent.ti.com (157.170.170.41) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 21 Aug 2018 22:10:52 -0500 Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Tue, 21 Aug 2018 22:10:51 -0500 Received: from legion.dal.design.ti.com (legion.dal.design.ti.com [128.247.22.53]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w7M3Ap8V012257; Tue, 21 Aug 2018 22:10:51 -0500 Received: from localhost (uda0274052.dhcp.ti.com [128.247.59.203]) by legion.dal.design.ti.com (8.11.7p1+Sun/8.11.7) with ESMTP id w7M3Apx12648; Tue, 21 Aug 2018 22:10:51 -0500 (CDT) From: Dave Gerlach To: Viresh Kumar , "Rafael J . Wysocki" CC: , , Tony Lindgren , Tero Kristo , Nishanth Menon , Stephen Boyd , Dave Gerlach , Keerthy J Subject: [PATCH] PM / OPP: Refactor counting of added OPPs for v2 to avoid unsupported OPPs Date: Tue, 21 Aug 2018 22:10:35 -0500 Message-ID: <20180822031035.6937-1-d-gerlach@ti.com> X-Mailer: git-send-email 2.16.1 MIME-Version: 1.0 Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however on platforms making use of the opp-supported-hw property, _opp_add_static_v2 does not add OPPs that are not seen as supported on the platform but still returns success, as this is valid. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are supported and actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. In order to ensure the count variable reflects the number of OPPs actually in the table, increment it during the existing loop which walks the opp table to check if pstate is set and then use that for the aforementioned checks. Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Signed-off-by: Dave Gerlach --- drivers/opp/of.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/opp/of.c b/drivers/opp/of.c index 7af0ddec936b..f288f83a2e62 100644 --- a/drivers/opp/of.c +++ b/drivers/opp/of.c @@ -399,8 +399,6 @@ static int _of_add_opp_table_v2(struct device *dev, struct device_node *opp_np) /* We have opp-table node now, iterate over it and add OPPs */ for_each_available_child_of_node(opp_np, np) { - count++; - ret = _opp_add_static_v2(opp_table, dev, np); if (ret) { dev_err(dev, "%s: Failed to add OPP, %d\n", __func__, @@ -411,15 +409,22 @@ static int _of_add_opp_table_v2(struct device *dev, struct device_node *opp_np) } } + /* + * Iterate over the list of OPPs that were actually added, as + * OPPs not supported by the hardware will be ignored by + * _opp_add_static_v2 above. + */ + list_for_each_entry(opp, &opp_table->opp_list, node) { + count++; + pstate_count += !!opp->pstate; + } + /* There should be one of more OPP defined */ if (WARN_ON(!count)) { ret = -ENOENT; goto put_opp_table; } - list_for_each_entry(opp, &opp_table->opp_list, node) - pstate_count += !!opp->pstate; - /* Either all or none of the nodes shall have performance state set */ if (pstate_count && pstate_count != count) { dev_err(dev, "Not all nodes have performance state set (%d: %d)\n", -- 2.16.1