linux-kernel - RE: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking

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:   Fri, 1 Sep 2017 21:38:13 +0000
From:   Ryan Lee <RyanS.Lee@...imintegrated.com>
To:     Mark Brown <broonie@...nel.org>
CC:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "kuninori.morimoto.gx@...esas.com" <kuninori.morimoto.gx@...esas.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ryan.lee.maxim@...il.com" <ryan.lee.maxim@...il.com>
Subject: RE: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking

>-----Original Message-----
>From: Mark Brown [mailto:broonie@...nel.org]
>Sent: Thursday, August 31, 2017 4:44 AM
>To: Ryan Lee <RyanS.Lee@...imintegrated.com>
>Cc: lgirdwood@...il.com; perex@...ex.cz; tiwai@...e.com;
>kuninori.morimoto.gx@...esas.com; alsa-devel@...a-project.org; linux-
>kernel@...r.kernel.org; ryan.lee.maxim@...il.com
>Subject: Re: [PATCH 2/9] ASoC: max98927: Added controls for Envelope tracking
>
>On Mon, Aug 28, 2017 at 04:30:54PM -0700, Ryan Lee wrote:
>
>>  	/* Envelope Tracking configuration */
>>  	regmap_write(max98927->regmap,
>>  		MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM,
>> -		0x08);
>> +		0x0A);
>>  	regmap_write(max98927->regmap,
>>  		MAX98927_R0086_ENV_TRACK_CTRL,
>>  		0x01);
>> -	regmap_write(max98927->regmap,
>> -		MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ,
>> -		0x10);
>
>Why are we changing the defaults here?  It was understandable to have a fixed
>default that differed from the chip value when there was no control but now
>there is a control and we're changing the default again for some undocumented
>reason.  It'd be better to leave the values here to avoid breaking compatibility
>with existing users and let users who need different values change things using
>the newly added controls.

Thank you for feedback. Let me keep existing value.
I still need to remove regmap_write for R:0x87 because it is read-only register.