linux-kernel - Re: [PATCH] ASoC: arizona: Make logging of FLL calculations clearer

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: <56CDEAD4.1050405@opensource.wolfsonmicro.com>
Date:	Wed, 24 Feb 2016 17:39:32 +0000
From:	Richard Fitzgerald <rf@...nsource.wolfsonmicro.com>
To:	Mark Brown <broonie@...nel.org>
CC:	<lgirdwood@...il.com>, <patches@...nsource.wolfsonmicro.com>,
	<alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: arizona: Make logging of FLL calculations clearer

On 24/02/16 04:08, Mark Brown wrote:
> On Tue, Feb 23, 2016 at 02:16:32PM +0000, Richard Fitzgerald wrote:
>> The debug logging of FLL calculations was confusing. Values were
>> printed in hex without indicating this by a leading 0x, and
>> despite these normally being required in decimal. Also where the
>> register value isn't the actual value (it s a power-of-two or
>> 0 means 1, 1 means 2, ...)  it was unclear whether the actual or
>> register value was shown.
> I think that stuff was originally based on the way the datasheets quote
> things:
>
>> -	arizona_fll_dbg(fll, "FRATIO=%x(%d) OUTDIV=%x REFCLK_DIV=%x\n",
> the hex(decimal) but there is certainly very familiar from some of
> those.
Indeed, and it was fine on the first codec. Now we've got various 
revisions of the FLL with some fields having different meanings, human 
error started to creep into interpreting the debug.