From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64B98C433F5 for ; Mon, 16 May 2022 13:28:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238226AbiEPN2A (ORCPT ); Mon, 16 May 2022 09:28:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240349AbiEPN0m (ORCPT ); Mon, 16 May 2022 09:26:42 -0400 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6617227CFD for ; Mon, 16 May 2022 06:26:41 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9590232009B0; Mon, 16 May 2022 09:26:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 16 May 2022 09:26:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1652707599; x=1652793999; bh=EE 1OM8mFf6szxlFaLiA0eUp/0epjQT6xgcPJbgOLty4=; b=xGDV3H5v47GXPMlwtE bnnGhPaJ/Qk8cIz5WF+QOYKkKsVo56rZfDRxRkhZD2OQaB7dEprn3QzYA52/z55a d1SY++BllZSgBBIfpvEz1h0pYCDHfpEg4eIEmAkygzGdYx9InsRSprrrgBlF9mSC MBWuDMI3t5S8vxEZP+F/ADRQbmlPWPt9UxE8j/VkGjGmCQNIFVMFBovbAWMs2X0g 5QU3e/W00pLsltkJ+8sT+GES20DTXAalS9bsicgf7XqqkPWfYGIskY1cbvSIoRRP SA0T1i+hfJZZR4i6pJDeS8cVHuKdZLqKtOY+YSDAhMvf6+M9KHM23Axe8wx7Pk1T h6DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1652707599; x=1652793999; bh=EE1OM8mFf6szxlFaLiA0eUp/0epjQT6xgcP JbgOLty4=; b=eQpPGj2JFyCEeuFTqkLMnBe72fy7R9JCa4tp/Q59au2M4RRG7ZG /sFSDLX4Hp/KcAf+omf7SLQVv0EiNXwo0GRPysXKASIV8rHcQVmwES5zGxiZdJ7d jSxFw/C7dWYfWOzEUy6XjqzIFm/J5N5odT75GJ3XrVZ4S9hFeS3XJwEndVRdDaDo yU/0x9hg2Z9kfrWL+PrUWv9UsqbqTpfF18o+alCJkvl9UdoJcPSyF+JRQDOBUlrq i8tKhqrstit5f+8wBPPeTfIND7wljKJpdCT6+ZhN8gmoxTusLS9pNL5v3Dav4d9o n/Hm8nDEN0UkN+Eo+RYdKdBtD6PONVjzjKQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrheehgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekfeetudfhkeejiefhtedugfeuvdevkeekteetkefhkefhtdelgfefuddv jefhnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepmh grgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 May 2022 09:26:38 -0400 (EDT) From: Maxime Ripard To: linux-clk@vger.kernel.org, Mike Turquette , Stephen Boyd Cc: Yassine Oudjana , Naresh Kamboju , Dmitry Baryshkov , Tony Lindgren , Neil Armstrong , Alexander Stein , Marek Szyprowski , Jerome Brunet , Maxime Ripard Subject: [PATCH v5 19/28] clk: Add our request boundaries in clk_core_init_rate_req Date: Mon, 16 May 2022 15:25:18 +0200 Message-Id: <20220516132527.328190-20-maxime@cerno.tech> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220516132527.328190-1-maxime@cerno.tech> References: <20220516132527.328190-1-maxime@cerno.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org The expectation is that a new clk_rate_request is initialized through a call to clk_core_init_rate_req(). However, at the moment it only fills the parent rate and clk_hw pointer, but omits the other fields such as the clock rate boundaries. Some users of that function will update them after calling it, but most don't. As we are passed the clk_core pointer, we have access to those boundaries in clk_core_init_rate_req() however, so let's just fill it there and remove it from the few callers that do it right. Tested-by: Alexander Stein # imx8mp Tested-by: Marek Szyprowski # exynos4210, meson g12b Signed-off-by: Maxime Ripard --- drivers/clk/clk.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 8952c5c71af2..3a94d3e76f59 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1389,6 +1389,7 @@ static void clk_core_init_rate_req(struct clk_core * const core, return; req->rate = rate; + clk_core_get_boundaries(core, &req->min_rate, &req->max_rate); parent = core->parent; if (parent) { @@ -1483,7 +1484,6 @@ unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate) struct clk_rate_request req; clk_core_init_rate_req(hw->core, &req, rate); - clk_core_get_boundaries(hw->core, &req.min_rate, &req.max_rate); ret = clk_core_round_rate_nolock(hw->core, &req); if (ret) @@ -1516,7 +1516,6 @@ long clk_round_rate(struct clk *clk, unsigned long rate) clk_core_rate_unprotect(clk->core); clk_core_init_rate_req(clk->core, &req, rate); - clk_core_get_boundaries(clk->core, &req.min_rate, &req.max_rate); ret = clk_core_round_rate_nolock(clk->core, &req); @@ -2022,9 +2021,6 @@ static struct clk_core *clk_calc_new_rates(struct clk_core *core, if (clk_core_can_round(core)) { struct clk_rate_request req; - req.min_rate = min_rate; - req.max_rate = max_rate; - clk_core_init_rate_req(core, &req, rate); ret = clk_core_determine_round_nolock(core, &req); @@ -2225,7 +2221,6 @@ static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core, return cnt; clk_core_init_rate_req(core, &req, req_rate); - clk_core_get_boundaries(core, &req.min_rate, &req.max_rate); ret = clk_core_round_rate_nolock(core, &req); -- 2.36.1