linux-kernel - Re: [PATCH] ALSA: Don't cold reset AC97 codecs in some ICH chipsets

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:	Wed, 28 Jan 2009 13:52:59 -0200
From:	Thadeu Lima de Souza Cascardo <cascardo@...oscopio.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: Don't cold reset AC97 codecs in some ICH chipsets

On Wed, Jan 28, 2009 at 04:20:12PM +0100, Takashi Iwai wrote:
> At Wed, 28 Jan 2009 12:40:42 -0200,
> Thadeu Lima de Souza Cascardo wrote:
> > 
> > Check in a quirk list if it should do cold reset when AC97 power saving
> > is enabled. Some devices do not resume properly when cold reset,
> > although power saving works OK.
> > 
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@...oscopio.com>
> 
> Thanks, applied now.
> 
> ... and soon I found a build error when CONFIG_SND_AC97_POWERSAVE=n.
> Fixed, too :)

Sorry for this one. I've cleaned the modules and built them again with a
changed config. Must have done something wrong in the build. Thanks for
the fix.

Regarding the warning fix in 92aab0a0, it is related to this commit:
248c982a, which was proposed by you during our previous discussion, and
didn't really fix my problem.

I've been watching your tree ever since and this patch has been in your
master branch since then, perhaps awaiting some conclusion about this
issue.

Do you think it solves any problems for other device models? In my case,
if the cold reset was done, this would simply not work.

Looking closer to the patch now, I see a point in keeping it, which may
be the reason you did so. It will make the resume faster in those cases
the init_bits are different from what the driver though would be there.

In this case, I think the log message should be more clear about that,
since it seems to indicate that the commit makes the driver wait for
more codecs (all codec slots) than before the commit.

Regards,
Cascardo.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)