linux-kernel - Re: [PATCH V2] clk: qcom: clk-alpha-pll: Use determine_rate instead of round

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 Sep 2023 09:33:38 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Stephen Boyd <sboyd@...nel.org>,
        Devi Priya <quic_devipriy@...cinc.com>, agross@...nel.org,
        andersson@...nel.org, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        mturquette@...libre.com
Cc:     quic_saahtoma@...cinc.com
Subject: Re: [PATCH V2] clk: qcom: clk-alpha-pll: Use determine_rate instead
 of round_rate

On 5.09.2023 22:40, Stephen Boyd wrote:
> Quoting Devi Priya (2023-09-01 00:00:41)
>> The round_rate() API returns a long value as the errors are reported using
>> negative error codes. This leads to long overflow when the clock rate
>> exceeds 2GHz.As the clock controller treats the clock rate above signed
>> long max as an error, use determine_rate in place of round_rate as the
>> determine_rate API does not possess such limitations.
> 
> Does this fix something, or is it preparing for PLLs that run faster
> than 2GHz?
I did some grepping and we already have multiple of these.

E.g. SM8250 CAMCC PLL2 (zonda) goes (or well, should go) up to 3.6 GHz.

Today, only stromer PLL uses determine rate, but perhaps all of them
should.

I would not at all be surprised if many otherwise inexplicable bugs
went away with that change.

Konrad