[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3nyoulu5eba6eyo644crhbtog63jh7vockbp7dz6mxquj2omsn@j56kn6vkbktg>
Date: Wed, 5 Apr 2023 17:22:00 +0200
From: Maxime Ripard <maxime@...no.tech>
To: David Lechner <david@...hnology.com>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Andreas Färber <afaerber@...e.de>,
Manivannan Sadhasivam <mani@...nel.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
Max Filippov <jcmvbkbc@...il.com>,
Charles Keepax <ckeepax@...nsource.cirrus.com>,
Richard Fitzgerald <rf@...nsource.cirrus.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Luca Ceresoli <luca.ceresoli@...tlin.com>,
Sekhar Nori <nsekhar@...com>, Abel Vesa <abelvesa@...nel.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Matthias Brugger <matthias.bgg@...il.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Dinh Nguyen <dinguyen@...nel.org>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Prashant Gaikwad <pgaikwad@...dia.com>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Alessandro Zummo <a.zummo@...ertech.it>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Paul Cercueil <paul@...pouillou.net>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Chunyan Zhang <zhang.lyra@...il.com>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
linux-arm-kernel@...ts.infradead.org,
linux-actions@...ts.infradead.org, patches@...nsource.cirrus.com,
linux-stm32@...md-mailman.stormreply.com,
linux-mediatek@...ts.infradead.org,
linux-renesas-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linux-phy@...ts.infradead.org,
linux-rtc@...r.kernel.org, linux-sunxi@...ts.linux.dev,
alsa-devel@...a-project.org, linux-mips@...r.kernel.org
Subject: Re: [PATCH v3 54/65] clk: da8xx: clk48: Switch to determine_rate
Hi David,
On Wed, Apr 05, 2023 at 10:03:24AM -0500, David Lechner wrote:
> On 4/4/23 5:11 AM, Maxime Ripard wrote:
> > The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent
> > hook, but doesn't provide a determine_rate implementation.
> >
> > This is a bit odd, since set_parent() is there to, as its name implies,
> > change the parent of a clock. However, the most likely candidate to
> > trigger that parent change is a call to clk_set_rate(), with
> > determine_rate() figuring out which parent is the best suited for a
> > given rate.
> >
>
> As mentioned in my previous review, parent is selected by device
> tree and should never be changed after init.
Great minds think alike then, because the driver implements exactly
that, either before or after that patch.
That patch makes the current behaviour explicit but doesn't change it in
any way.
So I guess that means that I can add your Acked-by on the three patches
you reviewed with the same message?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists