From patchwork Fri Dec 1 21:52:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 120392 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp1678631qgn; Fri, 1 Dec 2017 13:52:47 -0800 (PST) X-Google-Smtp-Source: AGs4zMakUyptJMZOHKCSmEwggw563TJdWjEpM7PzJtP51bA1rf8Qy7i0sk1N9TLz0JCqeFQ5aD35 X-Received: by 10.99.123.14 with SMTP id w14mr7211883pgc.172.1512165167309; Fri, 01 Dec 2017 13:52:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512165167; cv=none; d=google.com; s=arc-20160816; b=ynYblFmybIyFMjDSy6V1msSoHeILR62fNiH3AKONAwtpe7ebcA0C8xkGphIGAvUcIg hvP7yZpPq7IiTOl/TdUd4oBcrZP8Vl/f+XJexaSk++w5UtAEyhuktwLoZyFY4KmrejtN aZ4tuVXy5VwyfCG0mvXgMN7Ao3oAUfJsvZMA6VpWn5Lm4z+GhhnRVlv29n8bIHqF/sYu IT4+X47RfskW2LV0dmtXh89QG4fLQI6MwrprcThfLsHPURfQhMZqBGAEekkluZy+PlZf oYG2m7AVpb+Uz6Ngl+IZnNBOkHMb/3YPOkg2oNmwI5Kq18Xh5lI37OP5YnzK4jhKzNBo 2Kow== 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=x6/6Kk0+CmLoTS3WbV3hSeRPHiEDFQVvvOu9AJAJsos=; b=mJuoUaN37avBT0WGqj+YVg5QFwRtAWzEblEwxQCOIp4WLzu0qUl7j2beThjWY8dI/4 10t4Xfz3W2HpBTnevogLMWYKGcr/7i8knGhKlmUiOma7oIfdburJTAhrrjcZ2STAfSt4 m+MYicHeYbFx4ENc0e6NPu8Gd+L9/voAY1eB/Y4SEWfm8RezZIAFrDQl0E8hU1/QigAu mgjqd1bwtaLkO2D03FaFy0FwAm284bOGUyBaAL3NO5Tyf5mn2k0LGL9K2a3LmSTMKqag u8LNRrM0eTEgeyI1VoaqU+VoDzSXfDzgRFGv8CCOu3kauqJZqamkzulp+MY803Ga+TIt lP1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=G/8jQnkk; 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 1si5551759pls.720.2017.12.01.13.52.47; Fri, 01 Dec 2017 13:52:47 -0800 (PST) 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=G/8jQnkk; 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 S1751918AbdLAVwp (ORCPT + 28 others); Fri, 1 Dec 2017 16:52:45 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:42325 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751752AbdLAVwV (ORCPT ); Fri, 1 Dec 2017 16:52:21 -0500 Received: by mail-wm0-f67.google.com with SMTP id l141so5899243wmg.1 for ; Fri, 01 Dec 2017 13:52:21 -0800 (PST) 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=x6/6Kk0+CmLoTS3WbV3hSeRPHiEDFQVvvOu9AJAJsos=; b=G/8jQnkkUIARtqMjR5IQ/OdnRe10ys2QSwIosQg5Oln/p5ZYNCnacSC9OcYfNtvu7y I6SWvaeQuDVZ1wior9WvvqqdKvwYTFbvq6q83D3LIk1/A+FzDxIBT3chVEcXkHIteBsn QaUlINNx/Gr0MAYGkoLx8JTyEJOG6mKgusqZ39f6lQaESSbsHNJJHydwENpbCYlF9o2r +6U6B+cMqzc19wG9IleoY/f427Ert9OtgCYp0GrCWOJyvMI770lYm/NFq5Af/KoEzCGP ++FneF2qvuqSScgNgWmsd1fkoFzRC++8XbR2+oDpnFaL2W7AfBfcelvkaIj9wUbzD4dF 8A5g== 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=x6/6Kk0+CmLoTS3WbV3hSeRPHiEDFQVvvOu9AJAJsos=; b=N1KDmFUkNZFr9Ck8jHKKMfvkEhAYhKK4DI5Gx+6tCFcfAyeyNqKgBEyB/n+1hD+gXV zvZzP4sK+AdHDDPx/5gTLQcg5uKJ7yPM4w0J5r41WE2SzyA4FPr5kmfxqjrIfKKceiej AozuF0QxE/2rSqXitoTL26NB8tMqBXF8SMUOcvYA4GNUhqpTEp9g24cskQepaoDH5aK1 LmHjSUNkot/YMtA00BXD/23RfIobiIT6W8z3Ke2vEmaaE0eiGbFS5aFjfzYVm4SptLMu Jk3p9Fgvuggt/gmV2txzr0uSOuR9SY579cHu5Zy+wNeKcjq5okDCycyXnQ0gegbUNLJd MD/A== X-Gm-Message-State: AKGB3mJZ9756vG2xATr/iwAJxrtLCaVC2cTfdONZWVRK8UP58I9vtpUN K9pGzDzwi5Ti0eaDHH0CwudvFw== X-Received: by 10.28.8.67 with SMTP id 64mr2189604wmi.34.1512165140475; Fri, 01 Dec 2017 13:52:20 -0800 (PST) Received: from localhost.localdomain (cag06-3-82-243-161-21.fbx.proxad.net. [82.243.161.21]) by smtp.googlemail.com with ESMTPSA id m134sm2078804wmg.6.2017.12.01.13.52.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Dec 2017 13:52:19 -0800 (PST) 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 , Maxime Ripard Subject: [PATCH v5 10/10] clk: fix set_rate_range when current rate is out of range Date: Fri, 1 Dec 2017 22:52:00 +0100 Message-Id: <20171201215200.23523-11-jbrunet@baylibre.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171201215200.23523-1-jbrunet@baylibre.com> References: <20171201215200.23523-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") Tested-by: Maxime Ripard Acked-by: Michael Turquette Signed-off-by: Jerome Brunet --- drivers/clk/clk.c | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) -- 2.14.3 diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index edd965d8f41d..369933831705 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2010,6 +2010,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; @@ -2026,10 +2027,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)