linux-kernel - Re: snd_hda_intel/sst-acpi sound breakage on suspend/resume since 5.6-rc1

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: <0d01b2ce-9531-1a08-e632-4608ab894fbe@linux.intel.com>
Date:   Fri, 20 Mar 2020 11:21:40 +0800
From:   Keyon Jie <yang.jie@...ux.intel.com>
To:     Mark Brown <broonie@...nel.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     Dominik Brodowski <linux@...inikbrodowski.net>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        kuninori.morimoto.gx@...esas.com, alsa-devel@...a-project.org,
        curtis@...ainey.com, linux-kernel@...r.kernel.org, tiwai@...e.com,
        liam.r.girdwood@...ux.intel.com
Subject: Re: snd_hda_intel/sst-acpi sound breakage on suspend/resume since
 5.6-rc1



On 3/20/20 1:35 AM, Mark Brown wrote:
> On Thu, Mar 19, 2020 at 12:21:47PM -0500, Pierre-Louis Bossart wrote:
>> On 3/19/20 11:51 AM, Dominik Brodowski wrote:
> 
>>> That patch fixes the issue(s). I didn't even need to revert 64df6afa0dab
>>> ("ASoC: Intel: broadwell: change cpu_dai and platform components for SOF")
>>> on top of that. But you can assess better whether that patch needs care for
>>> other reasons; for me, this one-liner you have suggested is perfect.
> 
> Good news!
> 
>> .ignore_suspend is set for bdw-rt5677.c and bdw-rt5650.c as well. I don't
>> know if that was intentional.
> 
> The intended use case is for applications doing audio during suspend
> like telephony audio between the modem and CODEC on a phone or
> compressed audio playback.  I guess the compressed audio playback case
> could possibly apply with these systems though x86 suspend/resume is
> usually sufficiently heavyweight that it's surprising.

I think that's true, on many of SKL- intel platforms(byt, hsw, bdw), we 
are seeing this .ignore_suspend set with offload or deep buffer FE 
dai_links configured together.

So it looks we can't ignore calling codec's suspend/resume callbacks 
during the power cycle for rt286 codec(on the Dell XPS here), which is 
actually supported on Chromebook SAMUS(rt5677)?

Thanks,
~Keyon

>