linux-kernel - Re: [PATCH] staging: s5k3e2fx.c: simplify complexity by factoring

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: <2c0942db0912160909k1984f6b4w16c0503fed7d5d59@mail.gmail.com>
Date:	Wed, 16 Dec 2009 09:09:23 -0800
From:	Ray Lee <ray-lk@...rabbit.org>
To:	Justin Madru <jdm64@...ab.com>
Cc:	linux-kernel@...r.kernel.org, gregkh@...e.de, error27@...il.com
Subject: Re: [PATCH] staging: s5k3e2fx.c: simplify complexity by factoring

On Tue, Dec 15, 2009 at 12:52 PM, Justin Madru <jdm64@...ab.com> wrote:
> the code was looping, seting s_move[i] to the following calculations
>
> if (actual_step >= 0)
>        s_move[i] = ((((i + 1) * gain + 0x200) - (i * gain + 0x200)) / 0x400);
> else
>        s_move[i] = ((((i + 1) * gain - 0x200) - (i * gain - 0x200)) / 0x400);
>
> but, this code redues to the expression
>        s_move[i] = gain >> 10;
>
> The reason for the complexity was to generate a step function with
> integer division and rounding to land on specific values. But these calculations
> can be simplified to the following code:
>
>        gain = ((actual_step << 10) / 5) >> 10;
>        for (i = 0; i <= 4; i++)
>                s_move[i] = gain;
> ---
>  drivers/staging/dream/camera/s5k3e2fx.c |   10 +++-------
>  1 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/dream/camera/s5k3e2fx.c b/drivers/staging/dream/camera/s5k3e2fx.c
> index edba198..66582af 100644
> --- a/drivers/staging/dream/camera/s5k3e2fx.c
> +++ b/drivers/staging/dream/camera/s5k3e2fx.c
> @@ -1093,14 +1093,10 @@ static int32_t s5k3e2fx_move_focus(int direction, int32_t num_steps)
>
>        actual_step = step_direction * (int16_t)num_steps;
>        pos_offset = init_code + s5k3e2fx_ctrl->curr_lens_pos;
> -       gain = actual_step * 0x400 / 5;
> +       gain = ((actual_step << 10) / 5) >> 10;
>
> -       for (i = 0; i <= 4; i++) {
> -               if (actual_step >= 0)
> -                       s_move[i] = ((((i+1)*gain+0x200) - (i*gain+0x200))/0x400);
> -               else
> -                       s_move[i] = ((((i+1)*gain-0x200) - (i*gain-0x200))/0x400);
> -       }
> +       for (i = 0; i <= 4; i++)
> +               s_move[i] = gain;
>
>        /* Ring Damping Code */
>        for (i = 0; i <= 4; i++) {
> --
> 1.6.5.6

Okay, yes, that now generates the same numbers before and after.

More worryingly, however, it's now even more obvious that there's no
need for a five-element array here to hold the steps. They're all the
same size, so the array could have been removed along with the gain
variable and the expression ((actual_step << 10) / 5) >> 10 can be
used directly in at the top of the loop in the ring damping code
directly below, the only place that uses the s_move[5] array.

(There's no point in having an array of move values unless the
individual values differ, which makes the whole thing look like
there's a bug in the code compared to the original intent of, perhaps,
making large moves in the beginning and smaller toward the end. Dunno.
This is one of those 'ask the author' sorts of things.)

Regardless, that's not your fault, and not something that has to be
rolled into this patch, so feel free to add my

Reviewed-by: Ray Lee <ray-lk@...rabbit.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/