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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 33C2BC6FD18 for ; Wed, 29 Mar 2023 19:51:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 59BCC10E19C; Wed, 29 Mar 2023 19:51:04 +0000 (UTC) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7B04C10E19C for ; Wed, 29 Mar 2023 19:51:02 +0000 (UTC) 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 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-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Prashant Gaikwad , Alexandre Belloni , Liam Girdwood , Michael Turquette , Sekhar Nori , Alexandre Torgue , dri-devel@lists.freedesktop.org, Jaroslav Kysela , Paul Cercueil , Max Filippov , Thierry Reding , linux-phy@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, Abel Vesa , Kishon Vijay Abraham I , Geert Uytterhoeven , Samuel Holland , Chunyan Zhang , Takashi Iwai , linux-tegra@vger.kernel.org, Jernej Skrabec , Jonathan Hunter , Chen-Yu Tsai , NXP Linux Team , Orson Zhai , linux-mips@vger.kernel.org, Luca Ceresoli , linux-rtc@vger.kernel.org, linux-clk@vger.kernel.org, Charles Keepax , alsa-devel@alsa-project.org, Manivannan Sadhasivam , linux-kernel@vger.kernel.org, Sascha Hauer , linux-actions@lists.infradead.org, Richard Fitzgerald , Mark Brown , linux-mediatek@lists.infradead.org, Baolin Wang , Matthias Brugger , Pengutronix Kernel Team , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , Alessandro Zummo , linux-sunxi@lists.linux.dev, patches@opensource.cirrus.com, Peter De Schrijver , Nicolas Ferre , Andreas =?utf-8?Q?F=C3=A4rber?= , linux-renesas-soc@vger.kernel.org, Dinh Nguyen , Vinod Koul , Maxime Coquelin , David Lechner , Shawn Guo , Claudiu Beznea Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --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-- 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 28469C761AF for ; Wed, 29 Mar 2023 19:51:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To: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=Zt4UtCzkaSF8KVl93p0JmlgQ1qNyqizQv9dwIGkyHbg=; b=A2LK/qEgEA6A7YIlhfkTO8FNu/ vHsgV7AsAAcuVNvPQ5id6+tkOFobGIWZxahNy5Vs5idIJmnRaLV8WVubE6Y3zaSJRwuPtsKqFgzTt JTOx0Afb8gqkvyO0V371Ya7IqpuV89I8J//fAeD4J2k63YBO0a67uv6AvEWxH2awJQfMzHw1gK2Eu 0ieo152GXy+YEOVxBjtMLugRYdGp7A+cSqeWJl6P/uqS+IHh3a6Df92R5eEa/iKvtJe34DljNLtTR 4KHK7dSZg3pbrT229XHMvxbBWv/pXrp1mtCk8o+zH6svzvPbIHzQDHpws2DQSM5ZJLsNlz0kSBobK aiqLglPg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phbp5-001gXg-2Z; 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 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-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0713207492861195862==" Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org --===============0713207492861195862== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bx2st77tq2vvri5u" Content-Disposition: inline --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-- --===============0713207492861195862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy --===============0713207492861195862==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (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 3E6826FCB for ; Wed, 29 Mar 2023 19:50:58 +0000 (UTC) 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> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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> --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-- 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 1A7C6C6FD1D for ; Thu, 30 Mar 2023 16:07:18 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 524421F3; Thu, 30 Mar 2023 18:06:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 524421F3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1680192435; bh=olXhNneQzVkCpAu3yuydkamVGd/60CsTtNYj3SKZ6ls=; h=Date:From:To:Subject:References:In-Reply-To:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=TNEtcQdhCQ9ByVfbIT7bJPV92n0y3vJrMPPoYxAMhp5nfzHJiOu+KeXkXliYE7+EH MAtwt7KBXc887T8BCy1NZZ9b6ksowLAjw5bfjMBbmsUeTW4/We/HVkKiOD6QdPCIuK h3cPUo/Vddaph9hEl/0Wfw7oujKTwcT/FdPWuuhc= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id F3758F80290; Thu, 30 Mar 2023 18:06:24 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 1869CF80272; Wed, 29 Mar 2023 21:51:18 +0200 (CEST) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 60102F800C9 for ; Wed, 29 Mar 2023 21:51:00 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 60102F800C9 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=cerno.tech header.i=@cerno.tech header.a=rsa-sha256 header.s=fm3 header.b=bjfu/u+3; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=mDHZlaVn 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 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-MailFrom: maxime@cerno.tech X-Mailman-Rule-Hits: max-recipients X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-size; news-moderation; no-subject; digests; suspicious-header Message-ID-Hash: JCNGVJZ7YEEVO22JVIW4SRKFABCT5FZQ X-Message-ID-Hash: JCNGVJZ7YEEVO22JVIW4SRKFABCT5FZQ X-Mailman-Approved-At: Thu, 30 Mar 2023 16:06:21 +0000 CC: Mark Brown , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , 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 X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --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--