From patchwork Wed Feb 14 13:43:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 10218937 X-Patchwork-Delegate: mturquette@baylibre.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C3B23601D7 for ; Wed, 14 Feb 2018 13:48:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B1DB32869D for ; Wed, 14 Feb 2018 13:48:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A663628B56; Wed, 14 Feb 2018 13:48:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 518FF2896D for ; Wed, 14 Feb 2018 13:48:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030413AbeBNNsD (ORCPT ); Wed, 14 Feb 2018 08:48:03 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:44868 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030350AbeBNNnt (ORCPT ); Wed, 14 Feb 2018 08:43:49 -0500 Received: by mail-wr0-f194.google.com with SMTP id v65so15402899wrc.11 for ; Wed, 14 Feb 2018 05:43:48 -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=sx8n2q0ivN7mVA6n3yyaj8Jh74CEu0575DPKFiZAaxI=; b=HcCvjGFefsF3M1+WbqcaMXjtpQXLQvNnBs2AKxRtMy8s2MtFYO/c0DPIOmME33klUe HLWQTwZNaEP/AcATXbS7leT+CliYiJcKA0R9JEwvoizmrrobZJ2I4eKYqvEqZk1P3eQ6 wWmmJ4A1CQ7A54S4OTiDlLexTtReSlqoeTsn8u+EmI/smX3eFNOe9jVitJ9/DpcOt3Jv 2T1qPTkW/B6MUlS52FdtyhiMC7SdcMNvY0fTQpgDF1Me3p6wjQpFMJGCopNTSP1d+Oln EiqY+v2kTJgVoZhsJAxKRhCpjJFEl0myyS/HaintCZI2b1mf9B4DEGJfFY3BAYxZIY31 aX3A== 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=sx8n2q0ivN7mVA6n3yyaj8Jh74CEu0575DPKFiZAaxI=; b=K1Plf5NpIxZvH7gAZQkcAC9bTY6H2RUjON4xfTnaWerg/dKQnP/rNC8mc9zIkUtgKi K4ik6f8+O95tEoE4nmzD6pV4ZN/6OWLe9rxwJYau0rj9NxGp73n68400ycsEf1FRJmwy HtEOoMN+aoi6DlPxLL+o7MlA/F/mCMD4vgANC5U/ubUuphCs/1fnmC7zf3Sio9Xh8GC8 5nQlcfMCDvP9ZwC6zZMbydbzVegaQVhafoOKLxBkDdVyZJHA1FhGbt6OYXyds+9gVKzr 5SRxA5zduRwhkCWSryaEs0ymrWIpd/lfNuQZA9G9tWmlatHLMtTE/0JSj6ov0cISpNj3 xbOw== X-Gm-Message-State: APf1xPC2/mkVeFkpCVEbai7pEeXw260+RNRr1595RJEdpB9EomcC63mw D8WsVzfxQ/K6tTB5+n42QoKc3w== X-Google-Smtp-Source: AH8x225YdeTXcfobMSy4Y3WROwJy5m0fM0n1wNOXHUM0OOp3dt7Wvy6P0L/79o7TvJpP1QJbfQ94rg== X-Received: by 10.223.130.166 with SMTP id 35mr4857537wrc.251.1518615828006; Wed, 14 Feb 2018 05:43:48 -0800 (PST) Received: from boomer.lan (cag06-3-82-243-161-21.fbx.proxad.net. [82.243.161.21]) by smtp.googlemail.com with ESMTPSA id k5sm6337694wmg.47.2018.02.14.05.43.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Feb 2018 05:43:47 -0800 (PST) From: Jerome Brunet To: Michael Turquette , Stephen Boyd Cc: Jerome Brunet , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/8] clk: fix determine rate error with pass-through clock Date: Wed, 14 Feb 2018 14:43:35 +0100 Message-Id: <20180214134340.17242-4-jbrunet@baylibre.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180214134340.17242-1-jbrunet@baylibre.com> References: <20180214134340.17242-1-jbrunet@baylibre.com> Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If we try to determine the rate of a pass-through clock (a clock which does not implement .round_rate() nor .determine_rate()), clk_core_round_rate_nolock() will directly forward the call to the parent clock. In the particular case where the pass-through actually does not have a parent, clk_core_round_rate_nolock() will directly return 0 with the requested rate still set to the initial request structure. This is interpreted as if the rate could be exactly achieved while it actually cannot be adjusted. This become a real problem when this particular pass-through clock is the parent of a mux with the flag CLK_SET_RATE_PARENT set. The pass-through clock will always report an exact match, get picked and finally error when the rate is actually getting set. This is fixed by setting the rate inside the req to 0 when core is NULL in clk_core_round_rate_nolock() (same as in __clk_determine_rate() when hw is NULL) Fixes: 0f6cc2b8e94d ("clk: rework calls to round and determine rate callbacks") Signed-off-by: Jerome Brunet --- drivers/clk/clk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 0f686a9dac3e..a4b4e4d6df5e 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1125,8 +1125,10 @@ static int clk_core_round_rate_nolock(struct clk_core *core, { lockdep_assert_held(&prepare_lock); - if (!core) + if (!core) { + req->rate = 0; return 0; + } clk_core_init_rate_req(core, req);