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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Oct 2021 21:14:36 +0200
From:   Alex Bee <>
To:     Martin Blumenstingl <>
        Heiko Stübner <>,
Subject: Re: [PATCH v1 1/6] clk: divider: Implement and wire up
 .determine_rate by default

Am 14.10.21 um 23:34 schrieb Martin Blumenstingl:
> On Thu, Oct 14, 2021 at 2:11 PM Martin Blumenstingl
> <> wrote:
> [...]
>>> Reverting this commit makes it work again: Unless there is a quick and
>>> obvious fix for that, I guess this should be done for 5.15 - even if the
>>> real issue is somewhere else.
>> Reverting this patch is fine from the Amlogic SoC point of view.
>> The main goal was to clean up / improve the CCF code.
>> Nothing (that I am aware of) is going to break in Amlogic land if we
>> revert this.
> Unfortunately only now I realized that reverting this patch would also
> require reverting the other five patches in this series (since they
> depend on this one).
Indeed, that whole series would need have to reverted, which is clear 
(to me) when looking at the patches.
> For this reason I propose changing the order of the checks in
> clk-composite.c - see the attached patch (which I can send as a proper
> one once agreed that this is the way to go forward)

Yes, your patch papers over the actual issue (no best parent-selection 
in case determine_rate is used) and fixes it for now - as expected.

But it is not a long-term solution, as we will be at the same point, as 
soon as round_rate gets removed from clk-divider. For me, who is 
semi-knowledged in clock-framework, it was relatively hard to figure out 
what was going on. "I'll do this later" has often been heard here.

Though, I don't fully follow why moving the priority of determine_rate 
lower would have been necessary anyways: from what I understand 
determine_rate is expected to be the future-replacement of round_rate 
everywhere and should be preferred.

I guess it's up to the maintainers on how to proceed.


> Off-list Alex also suggested that I should use rate_ops.determine_rate
> if available.
> While I agree that this makes sense in general my plan is to do this
> in a follow-up patch.
> Changing the order of the conditions is needed anyways and it *should*
> fix the issue reported here (but I have no way of testing that
> unfortunately).
> Alex, it would be great if you (or someone with Rockchip boards) could
> test the attached patch and let me know if it fixes the reported
> problem.
> Best regards,
> Martin

Powered by blists - more mailing lists