linux-kernel - Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

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:   Mon, 10 Oct 2016 08:31:12 +0200
From:   Patrick Boettcher <patrick.boettcher@...teo.de>
To:     Nicholas Mc Guire <der.herr@...r.at>
Cc:     Olivier Grenie <olivier.grenie@...com.fr>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

Hi, der Herr Hofrat ;-)

On Sat, 8 Oct 2016 13:57:14 +0000
Nicholas Mc Guire <der.herr@...r.at> wrote:
> -                 lo6 |= (1 << 2) | 2;
> -         else
> -                 lo6 |= (1 << 2) | 1;
> +                 lo6 |= (1 << 2) | 2;    //SigmaDelta and Dither
> +         else {
> +                 if (state->identity.in_soc)
> +                         lo6 |= (1 << 2) | 2;    //SigmaDelta and
> Dither
> +                 else
> +                         lo6 |= (1 << 2) | 2;    //SigmaDelta and
> Dither
> +         }
> 
>  resulting in the current code-base of:
> 
>        if (Rest > 0) {
>                if (state->config->analog_output)
>                        lo6 |= (1 << 2) | 2;
>                else {
>                        if (state->identity.in_soc)
>                                lo6 |= (1 << 2) | 2;
>                        else
>                                lo6 |= (1 << 2) | 2;
>                }
>                Den = 255;
>        }
> 
>  The problem now is that the if and the else(if/else) are
>  all the same and thus the conditions have no effect. Further
>  the origninal code actually had different if/else - so I 
>  wonder if this is a cut&past bug here ?

I may answer on behalf of Olivier (didn't his address bounce?).

I don't remember the details, this patch must date from 2011 or
before, but at that time we generated the linux-driver from our/their
internal sources.

Updates in this area were achieved by a lot of thinking + a mix of trial
and error (after hours/days/weeks of RF hardware validation). 

This logic above has 3 possibilities: 

  - we use the analog-output, or 
  - we are using the digital one, then there is whether we are being in
    a SoC or not (SIP or sinlge chip).

At some point in time all values have been different. In the end, they
aren't anymore, but in case someone wants to try a different value,
there are placeholders in the code to easily inject these values.

Now the device is stable, maybe even obsolete. We could remove all the
branches resulting in the same value for lo6.

--
Patrick.