Quoting Daniel Latypov (2022-02-23 14:50:59)
> On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard <max...@cerno.tech> wrote:
> >
> > Let's test various parts of the rate-related clock API with the kunit
> > testing framework.
> >
> > Cc: kunit-...@googlegroups.com
> > Suggested-by: Stephen Boyd <sb...@kernel.org>
> > Signed-off-by: Maxime Ripard <max...@cerno.tech>
>
> Tested-by: Daniel Latypov <dlaty...@google.com>
>
> Looks good to me on the KUnit side.
> Two small nits below.
>
> FYI, I computed the incremental coverage for this series, i.e.:
> 1) applied the full series
> 2) computed the absolute coverage
>
> $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/clk
> --make_options=CC=/usr/bin/gcc-6 --kconfig_add=CONFIG_DEBUG_KERNEL=y
> --kconfig_add=CONFIG_DEBUG_INFO=y --kconfig_add=CONFIG_GCOV=y
> $ lcov -t "clk_tests" -o coverage.info -c -d .kunit/
> --gcov-tool=/usr/bin/gcov-6
This is cool. Thanks! Is it possible to add some 'coverage' command to
kunit so we don't have to recall this invocation?
>
> 3) intersected that with the total diff
This would also be cool to do automatically with a revision range.
>
> Incremental coverage for 3/9 files in --diff_file
> Total incremental: 99.29% coverage (281/283 lines)
> drivers/clk/clk.c: 84.62% coverage (11/13 lines)
> drivers/clk/clk_test.c: 100.00% coverage (269/269 lines)
> include/linux/clk.h: 100.00% coverage (1/1 lines)
>
> Missing lines are drivers/clk/clk.c:2397-8, i.e. this part of the diff:
> + if (ret) {
> + /* rollback the changes */
> + clk->min_rate = old_min; <- 2397
> + clk->max_rate = old_max; <- 2398
>
> These are from before and were just moved around.
We could trigger a failure in the provider when the rate is set, and
then we could call round_rate() again and make sure the boundaries from
before are maintained.
