All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Daniel Latypov <dlatypov@google.com>,
	Mike Turquette <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Phil Elwell <phil@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dom Cobley <dom@raspberrypi.com>,
	dri-devel@lists.freedesktop.org, kunit-dev@googlegroups.com
Subject: Re: [PATCH v6 02/12] clk: Introduce Kunit Tests for the framework
Date: Fri, 25 Feb 2022 14:44:04 -0800	[thread overview]
Message-ID: <20220225224406.1947FC340E7@smtp.kernel.org> (raw)
In-Reply-To: <20220225142606.6xpq4nzh7ldtkekk@houat>

Quoting Maxime Ripard (2022-02-25 06:26:06)
> Hi Stephen,
> 
> On Thu, Feb 24, 2022 at 02:54:20PM -0800, Stephen Boyd wrote:
> > Quoting Daniel Latypov (2022-02-23 14:50:59)
> > > On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > 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.
> 
> I tried to do that, and it turns out we can't, since we ignore the
> set_rate return code:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L2107
> 
> We could make determine_rate fail, but then clk_round_rate would fail as
> well and wouldn't allow us to test whether the boundaries are still in
> place.
> 

The test could still do it at a high level right? And when/if we decide
to bubble up the set_rate failure then we would be testing these lines.
Seems like a good idea to implement it with a TODO note that clk.c is
ignoring the set_rate clk_op returning failure.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Dom Cobley <dom@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Daniel Latypov <dlatypov@google.com>,
	dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org,
	Mike Turquette <mturquette@baylibre.com>,
	Phil Elwell <phil@raspberrypi.com>,
	kunit-dev@googlegroups.com
Subject: Re: [PATCH v6 02/12] clk: Introduce Kunit Tests for the framework
Date: Fri, 25 Feb 2022 14:44:04 -0800	[thread overview]
Message-ID: <20220225224406.1947FC340E7@smtp.kernel.org> (raw)
In-Reply-To: <20220225142606.6xpq4nzh7ldtkekk@houat>

Quoting Maxime Ripard (2022-02-25 06:26:06)
> Hi Stephen,
> 
> On Thu, Feb 24, 2022 at 02:54:20PM -0800, Stephen Boyd wrote:
> > Quoting Daniel Latypov (2022-02-23 14:50:59)
> > > On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > 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.
> 
> I tried to do that, and it turns out we can't, since we ignore the
> set_rate return code:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L2107
> 
> We could make determine_rate fail, but then clk_round_rate would fail as
> well and wouldn't allow us to test whether the boundaries are still in
> place.
> 

The test could still do it at a high level right? And when/if we decide
to bubble up the set_rate failure then we would be testing these lines.
Seems like a good idea to implement it with a TODO note that clk.c is
ignoring the set_rate clk_op returning failure.

  reply	other threads:[~2022-02-25 22:44 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 10:55 [PATCH v6 00/12] clk: Improve clock range handling Maxime Ripard
2022-02-23 10:55 ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 01/12] clk: Fix clk_hw_get_clk() when dev is NULL Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 02/12] clk: Introduce Kunit Tests for the framework Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 22:50   ` Daniel Latypov
2022-02-23 22:50     ` Daniel Latypov
2022-02-24 22:54     ` Stephen Boyd
2022-02-24 22:54       ` Stephen Boyd
2022-02-24 23:21       ` Daniel Latypov
2022-02-24 23:21         ` Daniel Latypov
2022-03-25 21:19         ` Stephen Boyd
2022-03-25 21:19           ` Stephen Boyd
2022-03-25 22:44           ` Daniel Latypov
2022-03-25 22:44             ` Daniel Latypov
2022-02-25 14:26       ` Maxime Ripard
2022-02-25 14:26         ` Maxime Ripard
2022-02-25 22:44         ` Stephen Boyd [this message]
2022-02-25 22:44           ` Stephen Boyd
2022-02-28 11:10           ` Maxime Ripard
2022-02-28 11:10             ` Maxime Ripard
2022-02-25 13:22     ` Maxime Ripard
2022-02-25 13:22       ` Maxime Ripard
2022-02-25 21:29       ` Daniel Latypov
2022-02-25 21:29         ` Daniel Latypov
2022-02-28 10:47         ` Maxime Ripard
2022-02-28 10:47           ` Maxime Ripard
2022-03-25 22:36           ` Daniel Latypov
2022-03-25 22:36             ` Daniel Latypov
2022-03-28  7:57             ` Maxime Ripard
2022-03-28  7:57               ` Maxime Ripard
2022-03-28 19:36               ` Daniel Latypov
2022-03-28 19:36                 ` Daniel Latypov
2022-03-30  7:43                 ` Maxime Ripard
2022-03-30  7:43                   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 03/12] clk: Enforce that disjoints limits are invalid Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 04/12] clk: Always clamp the rounded rate Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 05/12] clk: Use clamp instead of open-coding our own Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-24 22:51   ` Stephen Boyd
2022-02-24 22:51     ` Stephen Boyd
2022-02-23 10:55 ` [PATCH v6 06/12] clk: Always set the rate on clk_set_range_rate Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 07/12] clk: Add clk_drop_range Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 08/12] clk: bcm: rpi: Add variant structure Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 09/12] clk: bcm: rpi: Set a default minimum rate Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 10/12] clk: bcm: rpi: Run some clocks at the minimum rate allowed Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:55 ` [PATCH v6 11/12] drm/vc4: Add logging and comments Maxime Ripard
2022-02-23 10:55   ` Maxime Ripard
2022-02-23 10:56 ` [PATCH v6 12/12] drm/vc4: hdmi: Remove clock rate initialization Maxime Ripard
2022-02-23 10:56   ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220225224406.1947FC340E7@smtp.kernel.org \
    --to=sboyd@kernel.org \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dlatypov@google.com \
    --cc=dom@raspberrypi.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --cc=mturquette@baylibre.com \
    --cc=phil@raspberrypi.com \
    --cc=tim.gover@raspberrypi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.