All of
 help / color / mirror / Atom feed
From: Stephen Boyd <>
To: Michael Turquette <>,
	Stephen Boyd <>
Cc:,,, Guenter Roeck <>,
	kernel test robot <>,
	Maxime Ripard <>
Subject: Re: [PATCH 1/2] clk: Drive clk_leaf_mux_set_rate_parent test from clk_ops
Date: Mon, 09 Oct 2023 20:23:04 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Quoting Stephen Boyd (2023-09-12 10:55:30)
> Running this kunit test with lockdep enabled leads to warning splats
> about calling clk provider APIs without the clk_prepare lock held.  I
> proposed adding a wrapper around these APIs to grab the prepare lock so
> we can call them from anywhere, and Maxime implemented that approach[1],
> but it didn't look great. That's because we had to make more kunit
> testing APIs just to call code from a place that isn't a clk provider
> when the prepare lock isn't held.
> Instead of doing that, let's implement a determine_rate clk_op for a new
> leaf clk that is the child of the existing leaf clk. We can call
> __clk_determine_rate() on the existing leaf clk from there, and stash
> away the clk_rate_request struct to check once the clk_op returns. Drive
> that clk_op by calling clk_round_rate() to keep things similar to how it
> was before (i.e. nothing actually changes rate, just the new rate is
> determined). This silences the warning by driving the test from a
> clk_op where we know the prepare lock is held.
> While looking at this in more detail, it was determined that the code we
> intended to test in commit 262ca38f4b6e ("clk: Stop forwarding
> clk_rate_requests to the parent") wasn't actually tested. The call to
> __clk_determine_rate() wasn't actually getting to the newly introduced
> code under the CLK_SET_RATE_PARENT if condition in
> clk_core_round_rate_nolock() because the parent clk (the mux) could
> round rates. We introduce a new leaf and make sure the parent of that
> clk has no clk_ops so that we can be certain that the
> CLK_SET_RATE_PARENT condition in clk_core_round_rate_nolock() is
> evaluated.
> Reported-by: Guenter Roeck <>
> Closes:
> Reported-by: kernel test robot <>
> Closes:
> Cc: Maxime Ripard <>
> Link: [1]
> Fixes: 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent")
> Signed-off-by: Stephen Boyd <>
> ---

Applied to clk-next

  reply	other threads:[~2023-10-10  3:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 17:55 [PATCH 0/2] clk: Fix lockdep warnings in clk_test Stephen Boyd
2023-09-12 17:55 ` [PATCH 1/2] clk: Drive clk_leaf_mux_set_rate_parent test from clk_ops Stephen Boyd
2023-10-10  3:23   ` Stephen Boyd [this message]
2023-09-12 17:55 ` [PATCH 2/2] clk: Parameterize clk_leaf_mux_set_rate_parent Stephen Boyd
2023-10-10  3:23   ` Stephen Boyd
2023-09-19 11:01 ` [PATCH 0/2] clk: Fix lockdep warnings in clk_test 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \

* 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.