[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJtHcs8_671G33Ez@x1>
Date: Tue, 12 Aug 2025 09:53:54 -0400
From: Brian Masney <bmasney@...hat.com>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Sudeep Holla <sudeep.holla@....com>,
Cristian Marussi <cristian.marussi@....com>,
Chen Wang <unicorn_wang@...look.com>,
Inochi Amaoto <inochiama@...il.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
Paul Cercueil <paul@...pouillou.net>,
Keguang Zhang <keguang.zhang@...il.com>,
Taichi Sugaya <sugaya.taichi@...ionext.com>,
Takao Orito <orito.takao@...ionext.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Jacky Huang <ychuang3@...oton.com>,
Shan-Chun Hung <schung@...oton.com>,
Vladimir Zapolskiy <vz@...ia.com>,
Piotr Wojtaszczyk <piotr.wojtaszczyk@...esys.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Samuel Holland <samuel.holland@...ive.com>,
Yixun Lan <dlan@...too.org>,
Steen Hegelund <Steen.Hegelund@...rochip.com>,
Daniel Machon <daniel.machon@...rochip.com>,
UNGLinuxDriver@...rochip.com, Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Chunyan Zhang <zhang.lyra@...il.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Michal Simek <michal.simek@....com>,
Maxime Ripard <mripard@...nel.org>,
Andreas Färber <afaerber@...e.de>,
Manivannan Sadhasivam <mani@...nel.org>,
Sven Peter <sven@...nel.org>, Janne Grunau <j@...nau.net>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Neal Gompa <neal@...pa.dev>,
Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>,
Ray Jui <rjui@...adcom.com>, Scott Branden <sbranden@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Max Filippov <jcmvbkbc@...il.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Daniel Palmer <daniel@...ngy.jp>,
Romain Perier <romain.perier@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Bjorn Andersson <andersson@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Heiko Stuebner <heiko@...ech.de>,
Andrea della Porta <andrea.porta@...e.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Alim Akhtar <alim.akhtar@...sung.com>,
Qin Jian <qinjian@...lus1.com>, Viresh Kumar <vireshk@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Luca Ceresoli <luca.ceresoli@...tlin.com>,
Alex Helms <alexander.helms.jy@...esas.com>,
Linus Walleij <linus.walleij@...aro.org>,
Liviu Dudau <liviu.dudau@....com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
arm-scmi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
sophgo@...ts.linux.dev, linux-mips@...r.kernel.org,
imx@...ts.linux.dev, linux-riscv@...ts.infradead.org,
spacemit@...ts.linux.dev, linux-stm32@...md-mailman.stormreply.com,
patches@...nsource.cirrus.com, linux-actions@...ts.infradead.org,
asahi@...ts.linux.dev, linux-mediatek@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-rockchip@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, soc@...ts.linux.dev
Subject: Re: [PATCH 000/114] clk: convert drivers from deprecated
round_rate() to determine_rate()
On Tue, Aug 12, 2025 at 09:39:45PM +0800, Icenowy Zheng wrote:
> I was doing a patch to add divider setting support to clk-th1520-ap
> driver and sent patch now, should I remove round_rate from the next
> revision and just keep determine_rate? Is it safe to do this even if
> this patchset is not merged?
Yes, you only need to implement the determine_rate() clk op. Please
remove any references to the round_rate() clk op from your driver. If
you implement both, then only the determine_rate() clk op is actually
used by the clk core.
> In addition, will the clk_round_rate() API exported to other subsystems
> be affected?
No, that will stay as is, and with the same name. The underlying
implementation in the clk core uses the determine_rate() clk op.
Brian
Powered by blists - more mailing lists