linux-kernel - Re: [PATCH v4 3/3] ASoC: SOF: Intel: hda: Avoid checking jack on system suspend

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, 13 Jan 2021 10:36:25 +0200 (EET)
From:   Kai Vehmanen <kai.vehmanen@...ux.intel.com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
cc:     tiwai@...e.com, pierre-louis.bossart@...ux.intel.com,
        lgirdwood@...il.com, ranjani.sridharan@...ux.intel.com,
        kai.vehmanen@...ux.intel.com, daniel.baluta@....com,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@...a-project.org>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Marcin Rajwa <marcin.rajwa@...ux.intel.com>,
        broonie@...nel.org, Keyon Jie <yang.jie@...ux.intel.com>,
        open list <linux-kernel@...r.kernel.org>,
        Payal Kshirsagar <payalskshirsagar1234@...il.com>,
        "moderated list:SOUND - SOUND OPEN FIRMWARE SOF DRIVERS" 
        <sound-open-firmware@...a-project.org>
Subject: Re: [PATCH v4 3/3] ASoC: SOF: Intel: hda: Avoid checking jack on
 system suspend

Hi,

On Wed, 13 Jan 2021, Kai-Heng Feng wrote:

> System takes a very long time to suspend after commit 215a22ed31a1
> ("ALSA: hda: Refactor codec PM to use direct-complete optimization"):
[...]
> [  321.262505] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register 0x2b8000. -5
> [  328.426919] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register 0x2b8000. -5
> [  329.490933] ACPI: EC: interrupt blocked
> 
> That commit keeps the codec suspended during the system suspend. However,
> mute/micmute LED will clear codec's direct-complete flag by
> dpm_clear_superiors_direct_complete().

thanks Kai-Heng. This indeed explains why the regression is only seen on 
some systems (those with mute/micmute LED).

> This doesn't play well with SOF driver. When its runtime resume is
> called for system suspend, hda_codec_jack_check() schedules
> jackpoll_work which uses snd_hdac_is_power_on() to check whether codec

The commit explanation is a bit long, but this is indeed the problem. 
jackpoll_work() is common code (also used by snd-hda-intel) and SOF should 
align to snd-hda-intel and not call this directly to check jack status,
and especially not when going to system suspend.

There are a lot of details related to exact conditions when this problem 
triggers, but in the end, this is the main point.

> When direct-complete path is taken, snd_hdac_is_power_on() returns true
> and hda_jackpoll_work() is skipped by accident. So this is still not
> correct.

This doesn't really affect correctness of the patch, but I'm not sure if 
"accident" is the best characterization. This just explains why the bug 
was not hit in all cases.

snd_hdac_is_power_on() is called in a few places:
 - hda_jackpoll_work()
 - snd_hda_bus_reset_codecs()
 - snd_hda_update_power_acct()

In first two, the current logic seems appropriate (if runtime-pm is 
disabled, the action guarded by is_power_on() should not be taken). The 
third case seems suspicious and not sure if current is_power_on()
is appropriate.

So it's not quite clear whether hdaudio.h:snd_hdac_is_power_on() is
wrong or not. But that's now a separate discussion to have, and not 
related to this patchset anymore.

> Because devices suspend in reverse order (i.e. child first), it doesn't
> make much sense to resume an already suspended codec from audio
> controller. So avoid the issue by making sure jackpoll isn't used in
> system PM process.

The commit explanation is a bit long, but it is probably useful to have 
the background included. 

For the whole series:

Reviewed-by: Kai Vehmanen <kai.vehmanen@...ux.intel.com>

Br, Kai