linux-kernel - Re: [PATCH RESEND] clk: set initial best mux parent to current parent when determining rate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <SEZPR06MB695999603791369002D13378965E2@SEZPR06MB6959.apcprd06.prod.outlook.com>
Date: Fri, 1 Mar 2024 09:58:27 +0800
From: Yang Xiwen <forbidden405@...look.com>
To: Stephen Boyd <sboyd@...nel.org>,
 Michael Turquette <mturquette@...libre.com>,
 Yang Xiwen via B4 Relay <devnull+forbidden405.outlook.com@...nel.org>
Cc: linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] clk: set initial best mux parent to current parent
 when determining rate

On 3/1/2024 9:42 AM, Stephen Boyd wrote:
> Quoting Yang Xiwen (2024-02-28 18:33:11)
>> On 2/29/2024 10:25 AM, Stephen Boyd wrote:
>>>>>
>>>>> Is the problem that we're not using abs_diff()?
>>>>
>>>>
>>>> No, i think. It has nothing to do with the code here. It's because of
>>>> the initial best_parent/best_parent_rate.
>>>
>>> Alright.
> 
> I will have to fix this as well in a different patch.
> 
>>>
>>>>
>>>>>
>>>>> ----8<----
>>>>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>>>>> index a3bc7fb90d0f..91023345595f 100644
>>>>> --- a/drivers/clk/clk.c
>>>>> +++ b/drivers/clk/clk.c
>>>>> @@ -542,7 +542,7 @@ static bool mux_is_better_rate(unsigned long rate, unsigned long now,
>>>>>                          unsigned long best, unsigned long flags)
>>>>>  {
>>>>>       if (flags & CLK_MUX_ROUND_CLOSEST)
>>>>> -             return abs(now - rate) < abs(best - rate);
>>>>> +             return abs_diff(now, rate) < abs_diff(best, rate);
>>>>
>>>> Without this patch, the initial `best` rate would be always 0. This is
>>>> wrong for most cases, 0Hz might (usually) be unavailable. We should use
>>>> a valid rate(i.e. current rate) initially.
>>>
>>> Ok. But you set best to the parent rate. So why not use 'core->rate'
>>> directly as 'best'?
>>
>>
>> I can't remember exactly. I just add this piece of code and found it's
>> working. Is this field already filled prior to setting rate? Anyway,
>> your suggestion is very reasonable. Maybe dear clk maintainers can fix
>> it as i'm not familiar with clk core code.
> 
> Yes the 'struct clk_rate_request' is pre-filled with many details,
> including the rate of the clk and the current parent rate and parent hw
> pointer. I'm pretty sure you're trying to fix this fixme from clk_test.c
> 
> static const struct clk_ops clk_dummy_single_parent_ops = {
> 	/*
> 	 * FIXME: Even though we should probably be able to use
> 	 * __clk_mux_determine_rate() here, if we use it and call
> 	 * clk_round_rate() or clk_set_rate() with a rate lower than
> 	 * what all the parents can provide, it will return -EINVAL.
> 	 *
> 	 * This is due to the fact that it has the undocumented
> 	 * behaviour to always pick up the closest rate higher than the
> 	 * requested rate. If we get something lower, it thus considers
> 	 * that it's not acceptable and will return an error.
> 	 *
> 	 * It's somewhat inconsistent and creates a weird threshold
> 	 * between rates above the parent rate which would be rounded to
> 	 * what the parent can provide, but rates below will simply
> 	 * return an error.
> 	 */

If CLK_MUX_ROUND_CLOSEST is not specified, I think both setting lowest
possible rate and returning -EINVAL are okay, just as documented(It will
ONLY return a rate lower or equal to the rate requested). But if
CLK_MUX_ROUND_CLOSEST is specified, the behavior would be wrong in no doubt.

I don't know which behavior consumers would expect. Maybe some consumer
code has already been relying on this (undocumented) behavior.

This patch indeed also has an influence on clocks without
CLK_MUX_ROUND_CLOSEST. So you are right, I'll have to fix doc for
clk_mux_determine_rate too.

-- 
Best regards,
Yang Xiwen