linux-kernel - Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

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: <CAK8P3a3mc_sYczyKiaDoQLTTwDj2odwHJ5LFNAOb4RaRyh0YLQ@mail.gmail.com>
Date:   Thu, 2 Apr 2020 23:16:22 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Guru Das Srinagesh <gurus@...eaurora.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Linux PWM List <linux-pwm@...r.kernel.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Subbaraman Narayanamurthy <subbaram@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        David Collins <collinsd@...eaurora.org>
Subject: Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

On Thu, Apr 2, 2020 at 10:16 PM Guru Das Srinagesh <gurus@...eaurora.org> wrote:
> On Tue, Mar 31, 2020 at 10:49:29PM +0200, Thierry Reding wrote:
> > Doesn't that mean that anything below a 1 second period will be clamped
> > to just 0?
>
> True. How about this then?
>
> int pwm_imx27_calc_period_cycles(struct pwm_state state,
>                                  unsigned long clk_rate,
>                                  unsigned long *period_cycles)
> {
>         u64 c1, c2;
>
>         c1 = clk_rate;
>         c2 = state->period;
>         if (c2 > c1) {
>                 c2 = c1;
>                 c1 = state->period;
>         }
>
>         if (!c1 || !c2) {
>                 pr_err("clk rate and period should be nonzero\n");
>                 return -EINVAL;
>         }
>
>         if (c2 <= div64_u64(U64_MAX, c1)) {
>                 c = c1 * c2;
>                 do_div(c, 1000000000);
>         } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) {
>                 do_div(c1, 1000);
>                 c = c1 * c2;
>                 do_div(c, 1000000);
>         } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) {
>                 do_div(c1, 1000000);
>                 c = c1 * c2;
>                 do_div(c, 1000);
>         } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) {
>                 do_div(c1, 1000000000);
>                 c = c1 * c2;
>         }
>
>         *period_cycles = c;
>
>         return 0;
> }
>
> ...
>
> ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
>                                    &period_cycles);
> if (ret)
>         return ret;
>
> I unit tested this logic out by calculating period_cycles using both the
> existing logic and the proposed one, and the results are as below.
>
> --------------------------------------------------------------------------------
>  clk_rate               period            existing            proposed
> --------------------------------------------------------------------------------
> 1000000000      18446744073709551615     18446744072    18446744073000000000
>                       (U64_MAX)
> --------------------------------------------------------------------------------
> 1000000000           4294967291          4294967291         4294967291
> --------------------------------------------------------------------------------
>
> Overflow occurs in the first case with the existing logic, whereas the
> proposed logic handles it correctly. As for the second case where there are
> more typical values of period, the proposed logic handles that correctly
> too.

This looks correct, but very expensive, and you don't really have to
go this far, given that c1 is guaranteed to be a 32-bit number, and
you divide by a constant in the end.

Why not do something like

#define SHIFT 41 /* arbitrarily picked, not too big, not too small */
#define MUL 2199 /* 2^SHIFT / NSEC_PER_SEC */
period_cycles = clk_get_rate(imx->clk_per) * ((state->period * MUL) >> SHIFT);

        Arnd