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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B3A03C6FD18 for ; Wed, 29 Mar 2023 19:51:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=S00Xp8JXjn19UH995q1FPsxfz6/qb923iCtN7jshDa0=; b=BHBvjpHDZVCoFHAf3lTltxMGMI AqCH3Z2L1tVeZzTvXNxDy5ABhjsFWYdJiiG8fFpJpJ90Em0RlKlDX8g4vvx0jTvqZNlsmKqjfiwS2 82OEXqHcPZZy8NYULapqbbpZuN/NZUNUyefFpiMY70Au3YSU+ij6KPUG4bO8dcSb430+WVL7PgC6f k0dz38F64lPJRcso018zdTLkjdMMhAxd7tAp2vG43eiN7IcLgip3h4yotJue3yL1SJvpe7Mb7yI8b T+9yg8RT7oQSaNsRIyPRHYxPeL/mFd+fdRwS1CSRoBD4/XHIS7VbMtpe4hGPo9QH99cGaNEexPTPk lsTKnJBw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phbp5-001gXZ-1H; Wed, 29 Mar 2023 19:51:07 +0000 Received: from wnew3-smtp.messagingengine.com ([64.147.123.17]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1phbp0-001gW0-2c; Wed, 29 Mar 2023 19:51:04 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id B22DC2B05BE1; Wed, 29 Mar 2023 15:50:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 29 Mar 2023 15:50:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:content-type: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=1680119453; x=1680126653; bh=S0 0Xp8JXjn19UH995q1FPsxfz6/qb923iCtN7jshDa0=; b=bjfu/u+3WNSfLMbwG8 kgDlb33yFeBpTyDn26O0i5sMcaQYMH5k+w0P2n88u/CL6nmHobkHURfCmf1/C29t U0Qh1AeatQqCeBn6lka/dn10E2764ErqPqb3njkwCEp0gR+damC3mrcUvTxoLGFt C8YUuH43zoflGPvolh5JgeGOuMjpcUVK2XMglwkAj5Jbl90JOiW6MmIBfFxsj47Z LmLClTdxuUi8kFNiCE0STmAKXFF18XHkXI+HXgSXZYmlUiBbZLpqDOcow+ybw2xE 2FoegJ/5RU8yvTqRDV9YushjRc122S3DH00UzJnafvUsGPLUeJnt1P45+mZXlwwx 9r5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id: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=fm2; t=1680119453; x=1680126653; bh=S00Xp8JXjn19U H995q1FPsxfz6/qb923iCtN7jshDa0=; b=mDHZlaVnXucLsPRdtiP08QfOw0gbw L+tUMJhcynxctO/kzDo9N9LThihIenJjo53qM0euM2lsFwMzIIJmLZaKDMEQ9gKS btQwIniilAJ2KR0keHWJin00kBMMw6Fvxj0Tqr2fZDydPMLtTJ9/sGRArw3nvLEJ Inl8nRAJ+p1On2TOo/Jkf5NvgfFrgD8xiz+wUxe+OLxZLqgad7dL+FZKdxkOCpJr jXFB1C2jlktQjz7Pf5BdwXfRgXBHnZg2CeqLIpNinGTcVjw+BWRP0a6XnT9W3OK0 vrpjM1vniY/j4v5fsA1EOzPEQz9MwxVgK2edMj2xcjAO4WZgtdvUtY6ug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdehiedgudeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgig ihhmvgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrf grthhtvghrnhepteefffefgfektdefgfeludfgtdejfeejvddttdekteeiffejvdfgheeh fffhvedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 29 Mar 2023 15:50:49 -0400 (EDT) Date: Wed, 29 Mar 2023 21:50:49 +0200 From: Maxime Ripard To: Stephen Boyd Cc: Mark Brown , 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 =?utf-8?Q?F=C3=A4rber?= , Jonathan Hunter , Abel Vesa , Charles Keepax , 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 , Max Filippov , Geert Uytterhoeven , linux-stm32@st-md-mailman.stormreply.com, alsa-devel@alsa-project.org, linux-mediatek@lists.infradead.org, linux-phy@lists.infradead.org, linux-mips@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-actions@lists.infradead.org, linux-clk@vger.kernel.org, AngeloGioacchino Del Regno , patches@opensource.cirrus.com, linux-tegra@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook Message-ID: <20230329195049.lbdbkbqu6zbq5xii@penduick> References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-43-f6736dec138e@cerno.tech> <20221104155123.qomguvthehnogkdd@houat> <20221107084322.gk4j75r52zo5k7xk@houat> <20221107152603.57qimyzkinhifx5p@houat> <5819b1362f35ce306e1b6d566bfd44e5.sboyd@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bx2st77tq2vvri5u" Content-Disposition: inline In-Reply-To: <5819b1362f35ce306e1b6d566bfd44e5.sboyd@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230329_125102_881557_31C99794 X-CRM114-Status: GOOD ( 35.85 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org --bx2st77tq2vvri5u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Stephen, On Wed, Mar 22, 2023 at 04:31:04PM -0700, Stephen Boyd wrote: > > It's also replacing one implicit behavior by another. The point of this > > series was to raise awareness on that particular point, so I'm not sure > > it actually fixes things. We'll see what Stephen thinks about it. > >=20 >=20 > Right. A decade ago (!) when determine_rate() was introduced we > introduced CLK_SET_RATE_NO_REPARENT and set it on each mux user (see > commit 819c1de344c5 ("clk: add CLK_SET_RATE_NO_REPARENT flag")). This > way driver behavior wouldn't change and the status quo would be > maintained, i.e. that clk_set_rate() on a mux wouldn't change parents. > We didn't enforce that determine_rate exists if the set_parent() op > existed at the same time though. Probably an oversight. >=20 > Most of the replies to this series have been "DT is setting the parent", > which makes me believe that there are 'assigned-clock-parents' being > used. Yes, that's my understanding as well. > The clk_set_parent() path is valid for those cases. Probably nobody > cares about determine_rate because they don't set rates on these clks. > Some drivers even explicitly left out determine_rate()/round_rate() > because they didn't want to have some other clk round up to the mux > and change the parent. >=20 > Eventually we want drivers to migrate to determine_rate op so we can get > rid of the round_rate op and save a pointer (we're so greedy). It's been > 10 years though, and that hasn't been done. Sigh! I can see value in > this series from the angle of migrating, but adding a determine_rate op > when there isn't a round_rate op makes it hard to reason about. What if > something copies the clk_ops or sets a different flag? Now we've just > added parent changing support to clk_set_rate(). What if the clk has > CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to > change rate. Fun bugs. >=20 > TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't > then the clk is a mux that doesn't want to support clk_set_rate(). Make > a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT > branch in clk_mux_determine_rate_flags() and call that directly from the > clk_ops so it is clear what's happening, > clk_hw_mux_same_parent_determine_rate() or something with a better name. > Otherwise migrate the explicit determine_rate op to this new function > and don't set the flag. >=20 > It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag > with this design, if the determine_rate clk_op can call the inner > wrapper function instead of __clk_mux_determine_rate*() (those > underscores are awful, we should just prefix them with clk_hw_mux_*() > and live happier). That should be another patch series. Sorry but it's not really clear to me what you expect in the v2 of this series (if you even expect one). It looks that you don't like the assignment-if-missing idea Mark suggested, but should I just rebase/resend or did you expect something else? Maxime --bx2st77tq2vvri5u Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZCSWmAAKCRDj7w1vZxhR xQXTAP0bPg2EVQxPktgSpE4coaiyyn0Cu6Bba/x8MkUcPgNRVQEAxpbYr0uDsXMC CE9ojO6fXNwPgqHm5ELQGJgnrvcQQQg= =B5xn -----END PGP SIGNATURE----- --bx2st77tq2vvri5u--