From: Stephen Boyd <sboyd@kernel.org> To: Daniel Latypov <dlatypov@google.com> Cc: Maxime Ripard <maxime@cerno.tech>, Mike Turquette <mturquette@baylibre.com>, linux-clk@vger.kernel.org, dri-devel@lists.freedesktop.org, Dave Stevenson <dave.stevenson@raspberrypi.com>, Phil Elwell <phil@raspberrypi.com>, Tim Gover <tim.gover@raspberrypi.com>, Dom Cobley <dom@raspberrypi.com>, kunit-dev@googlegroups.com Subject: Re: [PATCH v3 01/10] clk: Add Kunit tests for rate Date: Thu, 20 Jan 2022 20:34:06 -0800 [thread overview] Message-ID: <20220121043408.6C186C340E1@smtp.kernel.org> (raw) In-Reply-To: <CAGS_qxq9qFjx+Su_E5sQF5tsgPCyhzGMFEMZbVqPN=N6U+s+9g@mail.gmail.com> Quoting Daniel Latypov (2022-01-20 13:56:39) > On Thu, Jan 20, 2022 at 1:31 PM Stephen Boyd <sboyd@kernel.org> wrote: > > I was thinking this would be more generic so that one file tests clk.c > > and all the code in there, but I guess there may be config dependencies > > like CONFIG_OF that we may want to extract out and depend on > > differently. I'm not sure how kunit will handle testing different paths > > depending on build configuration so this approach may head off future > > problems. If it doesn't then we can always slam the test together. > > KUnit doesn't have hard technical limitations in this regard. > > You could have something like this > > static void my_optional_kunit_test(struct kunit *test) > { > #ifdef CONFIG_OPTIONAL_FEATURE > > # else > kunit_skip(test, "CONFIG_OPTIONAL_FEATURE is not enabled"); > #endif > } > > I think it's just a matter of what's least confusing to users. Ok, I see. Is there some way to have multiple configs checked into the tree so we can test different kernel configuration code paths? This discussion isn't really relevant to this patch so we can take this up in another thread if you like. > > > > > Maybe kunit should check that there was an EXPECT on return from the > > test. Daniel? > > Sorry, I'm not sure I understand the question. > > Are you saying you want kunit to flag cases like > static void empty_test(struct kunit *) {} > ? Yes. I'd like kunit to enforce that all tests have at least one EXPECT_*() in them.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org> To: Daniel Latypov <dlatypov@google.com> Cc: Dom Cobley <dom@raspberrypi.com>, Tim Gover <tim.gover@raspberrypi.com>, Dave Stevenson <dave.stevenson@raspberrypi.com>, Mike Turquette <mturquette@baylibre.com>, dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org, Maxime Ripard <maxime@cerno.tech>, Phil Elwell <phil@raspberrypi.com>, kunit-dev@googlegroups.com Subject: Re: [PATCH v3 01/10] clk: Add Kunit tests for rate Date: Thu, 20 Jan 2022 20:34:06 -0800 [thread overview] Message-ID: <20220121043408.6C186C340E1@smtp.kernel.org> (raw) In-Reply-To: <CAGS_qxq9qFjx+Su_E5sQF5tsgPCyhzGMFEMZbVqPN=N6U+s+9g@mail.gmail.com> Quoting Daniel Latypov (2022-01-20 13:56:39) > On Thu, Jan 20, 2022 at 1:31 PM Stephen Boyd <sboyd@kernel.org> wrote: > > I was thinking this would be more generic so that one file tests clk.c > > and all the code in there, but I guess there may be config dependencies > > like CONFIG_OF that we may want to extract out and depend on > > differently. I'm not sure how kunit will handle testing different paths > > depending on build configuration so this approach may head off future > > problems. If it doesn't then we can always slam the test together. > > KUnit doesn't have hard technical limitations in this regard. > > You could have something like this > > static void my_optional_kunit_test(struct kunit *test) > { > #ifdef CONFIG_OPTIONAL_FEATURE > > # else > kunit_skip(test, "CONFIG_OPTIONAL_FEATURE is not enabled"); > #endif > } > > I think it's just a matter of what's least confusing to users. Ok, I see. Is there some way to have multiple configs checked into the tree so we can test different kernel configuration code paths? This discussion isn't really relevant to this patch so we can take this up in another thread if you like. > > > > > Maybe kunit should check that there was an EXPECT on return from the > > test. Daniel? > > Sorry, I'm not sure I understand the question. > > Are you saying you want kunit to flag cases like > static void empty_test(struct kunit *) {} > ? Yes. I'd like kunit to enforce that all tests have at least one EXPECT_*() in them.
next prev parent reply other threads:[~2022-01-21 4:34 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-20 14:34 [PATCH v3 00/10] clk: Improve clock range handling Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 01/10] clk: Add Kunit tests for rate Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 21:31 ` Stephen Boyd 2022-01-20 21:31 ` Stephen Boyd 2022-01-20 21:56 ` Daniel Latypov 2022-01-20 21:56 ` Daniel Latypov 2022-01-21 4:34 ` Stephen Boyd [this message] 2022-01-21 4:34 ` Stephen Boyd 2022-01-21 5:25 ` Daniel Latypov 2022-01-21 5:25 ` Daniel Latypov 2022-01-22 1:51 ` Stephen Boyd 2022-01-22 1:51 ` Stephen Boyd 2022-01-20 14:34 ` [PATCH v3 02/10] clk: Always clamp the rounded rate Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 03/10] clk: Use clamp instead of open-coding our own Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 04/10] clk: Always set the rate on clk_set_range_rate Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 05/10] clk: Add clk_drop_range Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 06/10] clk: bcm: rpi: Add variant structure Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 07/10] clk: bcm: rpi: Set a default minimum rate Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 08/10] clk: bcm: rpi: Run some clocks at the minimum rate allowed Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 09/10] drm/vc4: Add logging and comments Maxime Ripard 2022-01-20 14:34 ` Maxime Ripard 2022-01-20 14:34 ` [PATCH v3 10/10] drm/vc4: hdmi: Remove clock rate initialization Maxime Ripard 2022-01-20 14:34 ` 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=20220121043408.6C186C340E1@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: linkBe 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.