Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Pengpeng Hou <hppiscas@163.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	patches@opensource.cirrus.com, linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/9] ASoC: wm8978: restore safe state after resume errors
Date: Wed, 14 Oct 2026 10:20:20 +0100	[thread overview]
Message-ID: <as9JVLHuaVcEavOb@opensource.cirrus.com> (raw)
In-Reply-To: <20261014032452.13456-8-hppiscas@163.com>

On Wed, Oct 14, 2026 at 11:24:50AM +0800, Pengpeng Hou wrote:
> wm8978_resume() ignores cache replay, bias restoration and PLL update
> results, allowing subsequent resume steps to run after a failed operation.
> 
> Stop at the first failure and request SND_SOC_BIAS_OFF on the error path.
> Bias OFF intentionally preserves PLL power, so also clear the power
> register as system suspend does. Keep the original failure if rollback
> reports another error. Restore cache-only mode and mark the cache dirty
> so later accesses do not write through a partially restored device.
> Re-enable write-through before a later replay attempt. A positive
> update_bits() result means that
> bits changed, not an error.
> 
> The bias callback currently does not propagate every register write error;
> the rollback is therefore best-effort, not a claim of verified hardware
> power-down. The ASoC wrapper continues its established best-effort resume.
> 
> The issue was found by our static-analysis tool and manually reviewed.
> 
> Fixes: 0d34e91596ef ("ASoC: add a WM8978 codec driver")
> Assisted-by: gpt 5
> Signed-off-by: Pengpeng Hou <hppiscas@163.com>
> ---
> Changes since v1:
> - restore cache-only mode and dirty state on replay failure
> - restore bias OFF on the error path, as Charles requested

I was more interested in a rational for either approach. But
probably adding it seems more logical to me.

> - also turn off PLL power, matching system suspend rather than bias OFF alone
> - preserve positive update_bits() success
> - send as one correctly threaded series, as Mark requested
> 
> Previous series:
> https://lore.kernel.org/all/20260906034321.86080-1-hppiscas@163.com/
> 
>  sound/soc/codecs/wm8978.c |   31 +++++++++++++++++++++++++++----
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c
> index 258bc9f88f520e4de034393d39317e07e731d1ad..f5d3f26cc21790a8dfc4bf909a5fc5d56ba8f577 100644
> --- a/sound/soc/codecs/wm8978.c
> +++ b/sound/soc/codecs/wm8978.c
> @@ -952,17 +952,40 @@ static int wm8978_resume(struct snd_soc_component *component)
>  {
>  	struct wm8978_priv *wm8978 = snd_soc_component_get_drvdata(component);
>  	struct snd_soc_dapm_context *dapm = snd_soc_component_to_dapm(component);
> +	int ret, err;
>  
>  	/* Sync reg_cache with the hardware */
> -	regcache_sync(wm8978->regmap);
> +	regcache_cache_only(wm8978->regmap, false);

Nothing ever set cache_only true? Surely you either want a
separate patch to add cache_only support, or to not do this.
Although given the driver appears to only support system suspend
I would assume there isn't much point in cache only.

Thanks,
Charles

  reply	other threads:[~2026-10-14  9:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  3:24 [PATCH v2 0/9] ASoC: stop dependent resume work after restore failures Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 1/9] ASoC: nau8821: restore safe state after resume errors Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 2/9] ASoC: nau8824: " Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 3/9] ASoC: nau8825: " Pengpeng Hou
2026-10-14 18:18   ` Ajay Kumar Nandam
2026-10-14  3:24 ` [PATCH v2 4/9] ASoC: rt5663: " Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 5/9] ASoC: rt5682s: " Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 6/9] ASoC: rt5682: " Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 7/9] ASoC: wm8978: " Pengpeng Hou
2026-10-14  9:20   ` Charles Keepax [this message]
2026-10-14  3:24 ` [PATCH v2 8/9] ASoC: rt5640: " Pengpeng Hou
2026-10-14  3:24 ` [PATCH v2 9/9] ASoC: rt5677: " Pengpeng Hou
2026-10-14 18:43   ` Ajay Kumar Nandam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=as9JVLHuaVcEavOb@opensource.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=broonie@kernel.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=hppiscas@163.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox