From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH v2 03/11] ASoC: fsl_easrc: Use guard() for spin locks
Date: Mon, 15 Jun 2026 09:48:46 +0000 [thread overview]
Message-ID: <20260615094847.12AF31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260615093824.115751-4-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch erroneously removes `return 0;` from the success path in `fsl_easrc_runtime_resume()`, causing it to unconditionally fall through to the error handler and disable the memory clock.
- [Medium] The function `fsl_easrc_runtime_resume` improperly mixes `goto`-based error handling with scope-based cleanup helpers (`scoped_guard`).
--
commit d28002047081c21222edc1134f1efc00e25fe426
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: fsl_easrc: Use guard() for spin locks
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
> diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
> index 114a6c0b6b730..edfd943197a00 100644
> --- a/sound/soc/fsl/fsl_easrc.c
> +++ b/sound/soc/fsl/fsl_easrc.c
[ ... ]
> @@ -2323,13 +2312,11 @@ static int fsl_easrc_runtime_resume(struct device *dev)
> regcache_mark_dirty(easrc->regmap);
> regcache_sync(easrc->regmap);
>
> - spin_lock_irqsave(&easrc->lock, lock_flags);
> - if (easrc_priv->firmware_loaded) {
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
> - goto skip_load;
> + scoped_guard(spinlock_irqsave, &easrc->lock) {
> + if (easrc_priv->firmware_loaded)
> + return 0;
> + easrc_priv->firmware_loaded = 1;
> }
[Severity: Medium]
Does this code improperly mix goto-based error handling with scope-based
cleanup helpers?
The function fsl_easrc_runtime_resume() now uses scoped_guard() but still
contains goto disable_mem_clk error handling further down.
According to the cleanup subsystem architecture rules, for a given routine,
all resources needing cleanup should be converted to scope-based cleanup, or
none of them should be. Mixing goto and scoped guards can lead to confusing
ownership semantics.
> - easrc_priv->firmware_loaded = 1;
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
>
> ret = fsl_easrc_get_firmware(easrc);
> if (ret) {
[ ... ]
> @@ -2377,9 +2364,6 @@ static int fsl_easrc_runtime_resume(struct device *dev)
> goto disable_mem_clk;
> }
>
> -skip_load:
> - return 0;
> -
> disable_mem_clk:
> clk_disable_unprepare(easrc->mem_clk);
> return ret;
[Severity: High]
Does removing this return statement cause a normal success path to fall
through to the error handler?
By removing the skip_load label and its return 0 statement, the normal
success path of fsl_easrc_runtime_resume() directly falls through to the
disable_mem_clk block.
This incorrectly disables the memory clock while returning 0 to indicate
success, potentially causing bus faults on subsequent register accesses.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615093824.115751-1-phucduc.bui@gmail.com?part=3
next prev parent reply other threads:[~2026-06-15 9:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 9:38 [PATCH v2 00/11] ASoC: fsl: Use guard() for mutex & spin locks phucduc.bui
2026-06-15 9:38 ` [PATCH v2 01/11] ASoC: fsl_asrc: Use guard() for " phucduc.bui
2026-06-15 9:51 ` sashiko-bot
2026-06-15 14:18 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 02/11] ASoC: fsl_audmix: " phucduc.bui
2026-06-15 14:30 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 03/11] ASoC: fsl_easrc: " phucduc.bui
2026-06-15 9:48 ` sashiko-bot [this message]
2026-06-15 14:24 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 04/11] ASoC: fsl_esai: " phucduc.bui
2026-06-15 9:52 ` sashiko-bot
2026-06-15 14:15 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 05/11] ASoC: fsl_spdif: " phucduc.bui
2026-06-15 9:52 ` sashiko-bot
2026-06-15 14:17 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 06/11] ASoC: fsl_ssi: Use guard() for mutex locks phucduc.bui
2026-06-15 14:25 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 07/11] ASoC: fsl_xcvr: Use guard() for spin locks phucduc.bui
2026-06-15 9:49 ` sashiko-bot
2026-06-15 14:19 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 08/11] ASoC: imx-audio-rpmsg: " phucduc.bui
2026-06-15 9:51 ` sashiko-bot
2026-06-15 14:17 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 09/11] ASoC: fsl_rpmsg: Use guard() for mutex & " phucduc.bui
2026-06-15 9:59 ` sashiko-bot
2026-06-15 14:12 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 10/11] ASoC: fsl: mpc5200_dma: Use guard() for " phucduc.bui
2026-06-15 9:57 ` sashiko-bot
2026-06-15 14:14 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 11/11] ASoC: fsl: mpc5200_psc_ac97: Use guard() for mutex locks phucduc.bui
2026-06-15 14:26 ` Frank Li
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=20260615094847.12AF31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=phucduc.bui@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.