linux-kernel - Re: [PATCH 1/2] ASoC: codecs: Use component driver suspend/resume

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: <bdb14543-e611-42d0-a603-300c0ea17335@sirena.org.uk>
Date: Wed, 29 Oct 2025 14:37:38 +0000
From: Mark Brown <broonie@...nel.org>
To: Claudiu <claudiu.beznea@...on.dev>
Cc: support.opensource@...semi.com, lgirdwood@...il.com, perex@...ex.cz,
	tiwai@...e.com, biju.das.jz@...renesas.com,
	prabhakar.mahadev-lad.rj@...renesas.com,
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org,
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/2] ASoC: codecs: Use component driver suspend/resume

On Wed, Oct 29, 2025 at 04:11:33PM +0200, Claudiu wrote:

> Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(),
> and snd_soc_pm_ops is associated with the soc_driver (defined in
> sound/soc/soc-core.c), and there is no parent-child relationship between
> the soc_driver and the DA7213 codec driver, the power management subsystem
> does not enforce a specific suspend/resume order between the DA7213 driver
> and the soc_driver.

The theory here is that the power management core uses the device
instantiation order for both suspend and resume (reversed on suspend) so
the fact that we use probe deferral to make sure that the card
components are ready should ensure that the card suspends before
anything in the card.  If that is no longer the case then we need to
ensure that all drivers have system PM ops which trigger the card, this
won't be a driver specific issue.

>  static int da7213_runtime_resume(struct device *dev)
>  {
>  	struct da7213_priv *da7213 = dev_get_drvdata(dev);
> -	int ret;
>  
> -	ret = regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies);
> -	if (ret < 0)
> -		return ret;
> -	regcache_cache_only(da7213->regmap, false);
> -	return regcache_sync(da7213->regmap);
> +	return regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies);
>  }

This seems obviously buggy, we just power on the device and don't sync
the register state.  If the device actually lost power during a runtime
suspend then we'll end up having a bad time.  There was also no mention
of runtime PM in the patch description...

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