[PATCH 000/114] clk: convert drivers from deprecated round_rate() to determine_rate()
Brian Masney
bmasney at redhat.com
Fri Aug 22 04:32:36 PDT 2025
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
More information about the linux-riscv
mailing list