linux-kernel - Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

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:	Sun, 5 Jun 2016 22:22:55 -0300
From:	Fabio Estevam <festevam@...il.com>
To:	Clemens Gruber <clemens.gruber@...ruber.com>
Cc:	Eric Nelson <eric@...int.com>, Mark Brown <broonie@...nel.org>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

Hi Clemens,

On Sun, Jun 5, 2016 at 8:16 PM, Clemens Gruber
<clemens.gruber@...ruber.com> wrote:

> I looked into this today and discovered the following:
>
> With my patch applied, if I reset the board just after playback, at the
> next boot, the sgtl5000_fill_defaults function does not succeed: Writing
> the default value 0x7060 to register 0x30 (CHIP_ANA_POWER) fails.
>
> How did CHIP_ANA_POWER change with my patch: Before, only
> LINREG_SIMPLE_POWERUP was cleared as is recommended in the datasheet
> when using the internal LDO, now both LINREG_SIMPLE_POWERUP and
> STARTUP_POWERUP are cleared, as is recommended when using external VDDD.
>
> But why does the SGTL5000 nack that default write to CHIP_ANA_POWER
> after a reboot, which interrupted the playback?
>
> The following patch from Eric solved the problem; one write fails but it
> continues setting the other registers and thus even if resetting a board
> during playback, the sound still works after reboot:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088356.html
> Another workaround might be to not even write a default value to
> CHIP_ANA_POWER, as in this patch from Eric:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088355.html
>
> What do you think we should do?

Shouldn't both patches be applied?