From patchwork Sun Sep 24 20:00:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 114147 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp1853996qgf; Sun, 24 Sep 2017 13:00:56 -0700 (PDT) X-Received: by 10.99.186.3 with SMTP id k3mr5575166pgf.149.1506283256208; Sun, 24 Sep 2017 13:00:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506283256; cv=none; d=google.com; s=arc-20160816; b=h7ShQHPB+nbjNUXkwNy929W5WUamYFFsd3YXt9jXKDW6vZA9+t8XgM2eB1r4LK7mdu Tj1qZA5Bfxu4T83xeKLfkP8q1pMAzIAbyE2jAIcDj9vC01oh1+HJrSC+RZlUSm9s6V9i QTgqu+1XgcsMnIJmVQJONaR1zo7femL9jlDDQF5HaiRku7pZ/md2oEj6gQummqahqLpF Y7ACZgBStJvnbnD9rYYeifsSe312aIaPzkYfWyb4YF3pGnk5VpOTddjIO77LpXZJGc/S nVRmC9yPJMCnfDyCSOncrlCm6qfeFrj5j7hvJd2zw9uhL273LSOE3+IV9qxs+eAY1s0q tJ0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=pIEP+YwainmQWJKJm1uzwYSWTEK7GuU+iJJ9nbaoAuo=; b=j3USsrgxS5aAOjwdmADEMBEtSVO8PN5paxpHbmdSHqhGOZvzyROS9oVzuLDPrSjNKm /2y0borUJitoOeRDIqO8fj82bAg0qbKYO1xL7T+aw77UTOns7IJnGO9f0ACYDFp4gASS 9XWwYCloziLVDbG01dJbxoe+ZxiFUQwruicB1hHRw1qX6hDLwN2jTX2rvZ+9Mrd5SkMl 2Zr5ZORFDKdQGC240OJXqWIUfdak2DRL/izDw67VfQZWi1J9gbucRlnQXkcvWA8fPX+1 bZfARJCm0+/pVBY/DGxZ//8HFMlg7eUCH25DHZz/dDJiOdbU+qTWNZKVM/h4IyK/rC7M nThQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=deYVan6x; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j18si3015104pgn.485.2017.09.24.13.00.55; Sun, 24 Sep 2017 13:00:56 -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=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=deYVan6x; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752982AbdIXUAx (ORCPT + 26 others); Sun, 24 Sep 2017 16:00:53 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:47345 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752948AbdIXUAu (ORCPT ); Sun, 24 Sep 2017 16:00:50 -0400 Received: by mail-wm0-f53.google.com with SMTP id r136so14357987wmf.2 for ; Sun, 24 Sep 2017 13:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=pIEP+YwainmQWJKJm1uzwYSWTEK7GuU+iJJ9nbaoAuo=; b=deYVan6xhEQpkED1mtWAzNwkby6bFD0Q2Ztp876yEC/GN+zg0Fi5pCEZPJkxwT110S ktNED25hrxPtlns8u0pvqL1VJAOa+zPoqQyY5OcdFCDgv6eX2pzZKUmgrS4Vj9oaDTyH /HrIcuU+6Y/ZGzNayCcQgB0J0aQQXCG2KFq63Ey/UTOL8Dq49TVZg0mF5qlBkou17AK1 yui+2Ija/oWV8eqe1j5xqvr7Q4BVzk57S8sIMUdk6gvH+OgVH86lUAJavSJAJvjfhZLw 33kkdwfslg01tyecmmKgeSX7N7HB9LE4iKQo4YPgpkz5hBBEBLMqs+B33sXi2p3OpByC YdnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=pIEP+YwainmQWJKJm1uzwYSWTEK7GuU+iJJ9nbaoAuo=; b=jO9u+gjbarZATC4LOfTYqBWOHo/9e9TiYwRsD7T2zxFzmR25snQvgE1wWonrAU61GV zrIE04Ard3FkciOh+YQJGR+TSkRmOKFf9X41Q517gjCZG4GK2Osav+L3GWsc+f9LR2ob HnFfqcxhRdzJirznPtfJFU4ZVH4BW3T08j1pWA4FCGQKEZaOnMnflSO8/GIiQTz4jDmL sc2vk4NYkX5UPFXQd1IguwJEzdTIjyA1FLLYC3dNRufepgmFg17Iql4zNMUPEoeRVldm YYPzbpPtCscdzQiyRDdmxTuXlSq90cAYkwcfuqjxDHRoB5U3nxfUhW5CTGHFkyOJ9WXO zfXA== X-Gm-Message-State: AHPjjUhwK+jkiRYovZBoBWOiXiS+i58P2P0Qtx8xB5NOgCg3vy+ry+F1 /6ikbrzh4lRyPSq54T4tnwkiYA== X-Google-Smtp-Source: AOwi7QCIFlfchcQpSZ1ljfRR5XsxQcg3QkSNL9JDCj25HdOQRTbCCKU5LFB+CAydoSVDuSiGz8w7fQ== X-Received: by 10.28.164.68 with SMTP id n65mr7939302wme.23.1506283248909; Sun, 24 Sep 2017 13:00:48 -0700 (PDT) Received: from localhost.localdomain (cag06-3-82-243-161-21.fbx.proxad.net. [82.243.161.21]) by smtp.googlemail.com with ESMTPSA id j5sm6786144wmg.8.2017.09.24.13.00.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Sep 2017 13:00:48 -0700 (PDT) From: Jerome Brunet To: Stephen Boyd , Michael Turquette Cc: Jerome Brunet , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Russell King , Linus Walleij , Quentin Schulz , Kevin Hilman , Peter De Schrijver Subject: [PATCH v4 10/10] clk: fix set_rate_range when current rate is out of range Date: Sun, 24 Sep 2017 22:00:30 +0200 Message-Id: <20170924200030.6227-11-jbrunet@baylibre.com> X-Mailer: git-send-email 2.13.5 In-Reply-To: <20170924200030.6227-1-jbrunet@baylibre.com> References: <20170924200030.6227-1-jbrunet@baylibre.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Calling clk_core_set_rate() with core->req_rate is basically a no-op because of the early bail-out mechanism. This may leave the clock in inconsistent state if the rate is out the requested range. Calling clk_core_set_rate() with the closest rate limit could solve the problem but: - The underlying determine_rate() callback needs to account for this corner case (rounding within the range, if possible) - if only round_rate() is available, we rely on luck unfortunately. Fixes: 1c8e600440c7 ("clk: Add rate constraints to clocks") Signed-off-by: Jerome Brunet --- drivers/clk/clk.c | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) -- 2.13.5 diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index cbfff541ec8a..8bc3d9d4c7ff 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1921,6 +1921,7 @@ EXPORT_SYMBOL_GPL(clk_set_rate_exclusive); int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max) { int ret = 0; + unsigned long old_min, old_max, rate; if (!clk) return 0; @@ -1937,10 +1938,38 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max) if (clk->exclusive_count) clk_core_rate_unprotect(clk->core); - if (min != clk->min_rate || max != clk->max_rate) { - clk->min_rate = min; - clk->max_rate = max; - ret = clk_core_set_rate_nolock(clk->core, clk->core->req_rate); + /* Save the current values in case we need to rollback the change */ + old_min = clk->min_rate; + old_max = clk->max_rate; + clk->min_rate = min; + clk->max_rate = max; + + rate = clk_core_get_rate_nolock(clk->core); + if (rate < min || rate > max) { + /* + * FIXME: + * We are in bit of trouble here, current rate is outside the + * the requested range. We are going try to request appropriate + * range boundary but there is a catch. It may fail for the + * usual reason (clock broken, clock protected, etc) but also + * because: + * - round_rate() was not favorable and fell on the wrong + * side of the boundary + * - the determine_rate() callback does not really check for + * this corner case when determining the rate + */ + + if (rate < min) + rate = min; + else + rate = max; + + ret = clk_core_set_rate_nolock(clk->core, rate); + if (ret) { + /* rollback the changes */ + clk->min_rate = old_min; + clk->max_rate = old_max; + } } if (clk->exclusive_count)