From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001ae601.pphosted.com (mx0b-001ae601.pphosted.com [67.231.152.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E2473229 for ; Mon, 7 Nov 2022 10:58:21 +0000 (UTC) Received: from pps.filterd (m0077474.ppops.net [127.0.0.1]) by mx0b-001ae601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2A75n7uC030088; Mon, 7 Nov 2022 04:56:55 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cirrus.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=PODMain02222019; bh=MTDWpx1hsSGPKEDqYGlpVHQIbEswPJLgPoSW4FILuto=; b=i917JrNjkH3z3a2XXOdwc3doHM6OAxz7LbDVUIm7C+E3Cwrb58ZxQpsKKdqXGk5Z9z+/ hzIdNQ85JqsCyNGRwGzs83o+jomuHbPhAuHnJILygojPwEG6jpejkauG5tvHq+6Mjx1T 10Yn1n9hWdF7kaZM8JMcssci6VZmHmvumMtu+EtvU3lJyidhtFDMwmr56awM5w5p+0ch stqQ4q3mYnrkiSj6po7T4la5GvjwlpX4RBmjPsI7iQ7y3uUL/hIt6CTV9TTf6ttWh4IS JztSITFuL9+F5l7b8BFUGCyo8869zZsKrryWoIr9+DG4ZaxCTT2UTGw8JJDMLIjOfV8b vg== Received: from ediex01.ad.cirrus.com ([84.19.233.68]) by mx0b-001ae601.pphosted.com (PPS) with ESMTPS id 3knm8pa27f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Nov 2022 04:56:54 -0600 Received: from ediex01.ad.cirrus.com (198.61.84.80) by ediex01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.15; Mon, 7 Nov 2022 04:56:53 -0600 Received: from ediswmail.ad.cirrus.com (198.61.86.93) by ediex01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server id 15.2.1118.15 via Frontend Transport; Mon, 7 Nov 2022 04:56:53 -0600 Received: from ediswmail.ad.cirrus.com (ediswmail.ad.cirrus.com [198.61.86.93]) by ediswmail.ad.cirrus.com (Postfix) with ESMTP id 0BFD7468; Mon, 7 Nov 2022 10:56:53 +0000 (UTC) Date: Mon, 7 Nov 2022 10:56:53 +0000 From: Charles Keepax To: Maxime Ripard CC: Stephen Boyd , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , Jaroslav Kysela , Shawn Guo , Fabio Estevam , Ulf Hansson , Claudiu Beznea , Michael Turquette , Dinh Nguyen , Paul Cercueil , Chunyan Zhang , Manivannan Sadhasivam , Andreas =?iso-8859-1?Q?F=E4rber?= , Jonathan Hunter , Abel Vesa , Alessandro Zummo , Peter De Schrijver , Orson Zhai , Alexandre Torgue , Prashant Gaikwad , Liam Girdwood , Alexandre Belloni , Samuel Holland , Matthias Brugger , Richard Fitzgerald , Vinod Koul , NXP Linux Team , Sekhar Nori , Kishon Vijay Abraham I , Linus Walleij , Takashi Iwai , David Airlie , Luca Ceresoli , Jernej Skrabec , Pengutronix Kernel Team , Baolin Wang , David Lechner , Sascha Hauer , Mark Brown , Max Filippov , Geert Uytterhoeven , , , , , , , , , AngeloGioacchino Del Regno , , , , , , , Subject: Re: [PATCH v2 65/65] clk: Warn if we register a mux without determine_rate Message-ID: <20221107105653.GE10437@ediswmail.ad.cirrus.com> References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-65-f6736dec138e@cerno.tech> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20221018-clk-range-checks-fixes-v2-65-f6736dec138e@cerno.tech> User-Agent: Mutt/1.5.21 (2010-09-15) X-Proofpoint-ORIG-GUID: LEBapgZqMTQa_vVOLP8DsF0yYR6qduTv X-Proofpoint-GUID: LEBapgZqMTQa_vVOLP8DsF0yYR6qduTv X-Proofpoint-Spam-Reason: safe On Fri, Nov 04, 2022 at 02:18:22PM +0100, Maxime Ripard wrote: > The determine_rate hook allows to select the proper parent and its rate > for a given clock configuration. On another hand, set_parent is there to > change the parent of a mux. > > Some clocks provide a set_parent hook but don't implement > determine_rate. In such a case, set_parent is pretty much useless since > the clock framework will always assume the current parent is to be used, > and we will thus never change it. > > This situation can be solved in two ways: > - either we don't need to change the parent, and we thus shouldn't > implement set_parent; > - or we don't want to change the parent, in this case we should set > CLK_SET_RATE_NO_REPARENT; > - or we're missing a determine_rate implementation. > > The latter is probably just an oversight from the driver's author, and > we should thus raise their awareness about the fact that the current > state of the driver is confusing. > > It's not clear at this point how many drivers are affected though, so > let's make it a warning instead of an error for now. > Commit message could probably use updated to make the new state of the chain. Thanks, Charles