mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chuan Liu <chuan.liu@amlogic.com>
To: Brian Masney <bmasney@redhat.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: Thu, 15 Jan 2026 10:37:55 +0800	[thread overview]
Message-ID: <fe437139-4c33-489f-90f9-44e3dd3b0f9e@amlogic.com> (raw)
In-Reply-To: <aWhDLNFtaoU7A-AN@redhat.com>

Hi Brian,

On 1/15/2026 9:30 AM, Brian Masney wrote:
> [ EXTERNAL EMAIL ]
> 
> 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.
> 

Perhaps it would be more appropriate to move the 
clk_core_check_boundaries() check before saving the previous values, 
like this:

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

	/* 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;

The changes in this patch are intended to avoid altering the original 
driver execution flow, while making the minimal modification to fix the 
issue where the range is incorrectly assigned.

> Brian
> 


  reply	other threads:[~2026-01-15  2:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-09  3:24 Chuan Liu via B4 Relay
2026-01-15  1:30 ` Brian Masney
2026-01-15  2:37   ` Chuan Liu [this message]
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=fe437139-4c33-489f-90f9-44e3dd3b0f9e@amlogic.com \
    --to=chuan.liu@amlogic.com \
    --cc=bmasney@redhat.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

all inboxes | Powered by JetHome®