Re: [PATCH v9 00/25] clk: More clock rate fixes and tests

From: Maxime Ripard <maxime@cerno.tech>
To: Mike Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-clk@vger.kernel.org
Cc: Jerome Brunet <jbrunet@baylibre.com>,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Alexander Stein <alexander.stein@ew.tq-group.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Yassine Oudjana <y.oudjana@protonmail.com>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v9 00/25] clk: More clock rate fixes and tests
Date: Fri, 2 Sep 2022 16:53:05 +0200	[thread overview]
Message-ID: <20220902145305.znvsrcrcjrpr343c@houat> (raw)
In-Reply-To: <20220816112530.1837489-1-maxime@cerno.tech>

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Stephen, Mike,

On Tue, Aug 16, 2022 at 01:25:05PM +0200, Maxime Ripard wrote:
> Thanks to the feedback I got on the previous series, I found and fixed a
> number of bugs in the clock framework and how it deals with rates,
> especially when it comes to orphan clocks.
> 
> In order to make sure this doesn't pop up again as a regression, I've
> extended the number of tests.
> 
> The first patch reintroduces the clk_set_rate_range call on clk_put, but
> this time will only do so if there was a range set on that clock to
> begin with. It should be less intrusive, and reduce the number of
> potential side effects considerably.
> 
> We then have a fix for the qcom rcg2 issue that has been reported
> recently.
> 
> All the other patches should be probably be flagged as fixes, but
> they've never seem to have shown any real-world issues until now, and
> they aren't all really trivial to backport either, so I'm not sure it's
> worth it.
> 
> There's also some documentation improvements for recalc_rate and
> clk_get_rate to hopefully make the documentation less ambiguous and
> acknowledge that recalc_rate() returning 0 on error is fine.

I'm not sure what to do at that point.

Back in July, you felt uncomfortable merging that series so close to the
merge window. I've sent a new series as soon as -rc1 was out, got a
kernelci run to test it and on a number of other platforms. And now
we're close to rc4, which means that you're going to bring the "we're
too late now for 6.1, let's target 6.2".

I believe this series fixes a number of real bugs in the CCF, in
addition to extending quite a lot the unit test coverage of the
framework. But if you just don't care, please just say so. I really
don't want to waste any more time rebasing and sending that series, and
pinging you on a regular basis if it's not going anywhere.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]