Message-ID: <aKhVVJPEPxCoKKjI@x1>
Date: Fri, 22 Aug 2025 07:32:36 -0400
From: Brian Masney <bmasney@...hat.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
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>,
	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()

Hi Krzysztof (and Stephen),

On Fri, Aug 22, 2025 at 08:31:08AM +0200, Krzysztof Kozlowski wrote:
> On 11/08/2025 17:17, Brian Masney via B4 Relay wrote:
> > The round_rate() clk ops is deprecated in the clk framework in favor
> > of the determine_rate() clk ops, so let's go ahead and convert the
> > various clk drivers using the Coccinelle semantic patch posted below.
> > I did a few minor cosmetic cleanups of the code in a few cases.
> 
> This is going to create huge conflicts and I did not find here any
> merging strategy.
> 
> What do you expect from us here?

That's a good question. You are right that there's a handful of drivers
where this will create a merge conflict with some other work that's been
posted this development cycle due to other unrelated changes. I suspect
the majority of these will still apply cleanly.

This series doesn't remove round_rate from the clk core, and I'll post
that change once everything else has been merged across the tree. I've
been trying to catch any new round_rate implementations that are posted
in review.

7 of the 114 patches in this series needs a v2 with a minor fix. I see
several paths forward to merging this. It's ultimately up to Stephen how
he wants to proceed.

- I send Stephen a PULL request with all of these patches with the minor
  cleanups to the 7 patches. Depending on the timing, Stephen can merge
  the other work first, and I deal with cleaning up the merge conflicts.
  Or he can if he prefers to instead.

- Stephen applies everyone else's work first to his tree, and then the
  good 107 patches in this series. He skips anything that doesn't apply
  due to other people's work and I follow up with a smaller series.

I would prefer to not to have to post a v2 114 patch series if
possible.

If I don't hear back from Stephen about how he wants to proceed, then
I'm planning to send him a PULL request the week of Sep 1st.

Does this sound good? I'm open to other suggestions.

Brian

Powered by blists - more mailing lists