linux-kernel - Re: [PATCH 2/2] soc: qcom: geni: geni_se_clk_freq

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]

Message-ID: <CAD=FV=WvCZt1NmG4vodDgD=qc4-ZEMLTMhfJyhX239p1jsOhSw@mail.gmail.com>
Date:   Thu, 6 Sep 2018 09:33:21 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Girish Mahadevan <girishm@...eaurora.org>,
        Dilip Kota <dkota@...eaurora.org>,
        Evan Green <evgreen@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-soc@...r.kernel.org>,
        David Brown <david.brown@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] soc: qcom: geni: geni_se_clk_freq_match() should
 always accept multiples

Hi,

On Wed, Sep 5, 2018 at 5:20 PM, Matthias Kaehlcke <mka@...omium.org> wrote:
> On Thu, Aug 30, 2018 at 11:36:12AM -0700, Douglas Anderson wrote:
>> The geni_se_clk_freq_match() has some strange semantics.  Specifically
>> it is defined with two modes:
>> 1. It can find a clock that's an exact multiple of the requested rate
>> 2. If can find a non-exact match but it can't handle multiples then
>
> nit: s/If/It/

Splleing was nvevr my strong suit.  Done.


>> +     best_delta = 0;
>>       for (i = 0; i < num_clk_levels; i++) {
>> -             if (!(tbl[i] % req_freq)) {
>> +             divider = DIV_ROUND_UP(tbl[i], req_freq);
>> +             new_delta = req_freq - tbl[i] / divider;
>> +             if (!best_delta || new_delta < best_delta) {
>
> nit: if you assigned best_delta to ULONG_MAX above you could omit the
> check for !best_delta here, better to read IMO.

Done.


> Looks good to me assuming that the statement "callers should always be
> able to handle a clock that is a multiple of the requested clock" is
> correct.

I think we should be OK given that currently there's no real callers.
If we really need to add another parameter to disallow multiples we
can always do it later.


> Reviewed-by: Matthias Kaehlcke <mka@...omium.org>

Thanks for the reviews!

-Doug