public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Masney <bmasney@redhat.com>
To: chuan.liu@amlogic.com
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: Ensure correct consumer's rate boundaries
Date: Wed, 14 Jan 2026 20:30:20 -0500	[thread overview]
Message-ID: <aWhDLNFtaoU7A-AN@redhat.com> (raw)
In-Reply-To: <20260109-fix_error_setting_clk_rate_range-v1-1-bae0b40e870f@amlogic.com>

Hi Chuan,

On Fri, Jan 09, 2026 at 11:24:22AM +0800, Chuan Liu via B4 Relay wrote:
> From: Chuan Liu <chuan.liu@amlogic.com>
> 
> If we were to have two users of the same clock, doing something like:
> 
> clk_set_rate_range(user1, 1000, 2000);
> clk_set_rate_range(user2, 3000, 4000);
> 
> Even when user2's call returns -EINVAL, the min_rate and max_rate of
> user2 are still incorrectly updated. This causes subsequent calls by
> user1 to fail when setting the clock rate, as clk_core_get_boundaries()
> returns corrupted boundaries (min_rate = 3000, max_rate = 2000).
> 
> To prevent this, clk_core_check_boundaries() now rollback to the old
> boundaries when the check fails.
> 
> Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
> ---
>  drivers/clk/clk.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 85d2f2481acf..0dfb16bf3f31 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2710,13 +2710,17 @@ static int clk_set_rate_range_nolock(struct clk *clk,
>  	 */
>  	rate = clamp(rate, min, max);
>  	ret = clk_core_set_rate_nolock(clk->core, rate);
> +
> +out:
>  	if (ret) {
> -		/* rollback the changes */
> +		/*
> +		 * Rollback the consumer’s old boundaries if check_boundaries or
> +		 * set_rate fails.
> +		 */
>  		clk->min_rate = old_min;
>  		clk->max_rate = old_max;
>  	}
>  
> -out:
>  	if (clk->exclusive_count)
>  		clk_core_rate_protect(clk->core);

This looks correct to me. Just a quick question though to possibly
simplify this further. Currently clk_set_rate_range_nolock() has the
following code:

        /* Save the current values in case we need to rollback the change */
        old_min = clk->min_rate;
        old_max = clk->max_rate;
        clk->min_rate = min;
        clk->max_rate = max;

        if (!clk_core_check_boundaries(clk->core, min, max)) {
                ret = -EINVAL;
                goto out;
        }

Since clk_core_check_boundaries() is a readonly operation, what do you
think about moving clk_core_check_boundaries above the code that saves the
previous values? That way we only need to rollback in the case where
set_rate() fails.

Brian


  reply	other threads:[~2026-01-15  1:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-09  3:24 [PATCH] clk: Ensure correct consumer's rate boundaries Chuan Liu via B4 Relay
2026-01-15  1:30 ` Brian Masney [this message]
2026-01-15  2:37   ` Chuan Liu
2026-01-15 13:01     ` Brian Masney
2026-01-16  9:32       ` Chuan Liu
2026-01-16 16:44         ` Brian Masney
2026-01-19 11:56           ` Chuan Liu

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=aWhDLNFtaoU7A-AN@redhat.com \
    --to=bmasney@redhat.com \
    --cc=chuan.liu@amlogic.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox