From: Takashi Iwai <tiwai@suse.de>
To: wangdich9700@163.com
Cc: tiwai@suse.com, david.rhodes@cirrus.com,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
wangdicheng <wangdicheng@kylinos.cn>
Subject: Re: [PATCH v2 3/3] ALSA: hda: Use scoped_guard() for open_mutex in azx_pcm_open()
Date: Tue, 14 Jul 2026 08:11:58 +0200 [thread overview]
Message-ID: <87ldbeje1d.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260710084009.665814-4-wangdich9700@163.com>
On Fri, 10 Jul 2026 10:40:09 +0200,
wangdich9700@163.com wrote:
>
> From: wangdicheng <wangdicheng@kylinos.cn>
>
> The companion function azx_pcm_close() already uses
> scoped_guard(mutex, &chip->open_mutex). Replace the manual
> mutex_lock/mutex_unlock pair in azx_pcm_open() with the same
> pattern for consistency.
>
> All goto targets are within the scoped_guard() block, avoiding
> the goto-jumping-out-of-scope pattern that is not recommended
> when using cleanup guards.
>
> No functional changes.
>
> Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
This one has also a combination of guard() and goto, which isn't a
good mix.
thanks,
Takashi
> ---
> sound/hda/common/controller.c | 158 +++++++++++++++++-----------------
> 1 file changed, 81 insertions(+), 77 deletions(-)
>
> diff --git a/sound/hda/common/controller.c b/sound/hda/common/controller.c
> index afec5c5546ec..04ae21cc5e5e 100644
> --- a/sound/hda/common/controller.c
> +++ b/sound/hda/common/controller.c
> @@ -584,86 +584,90 @@ static int azx_pcm_open(struct snd_pcm_substream *substream)
> int buff_step;
>
> snd_hda_codec_pcm_get(apcm->info);
> - mutex_lock(&chip->open_mutex);
> - azx_dev = azx_assign_device(chip, substream);
> - trace_azx_pcm_open(chip, azx_dev);
> - if (azx_dev == NULL) {
> - err = -EBUSY;
> - goto unlock;
> - }
> - runtime->private_data = azx_dev;
> -
> - runtime->hw = azx_pcm_hw;
> - if (chip->gts_present)
> - runtime->hw.info |= SNDRV_PCM_INFO_HAS_LINK_SYNCHRONIZED_ATIME;
> - runtime->hw.channels_min = hinfo->channels_min;
> - runtime->hw.channels_max = hinfo->channels_max;
> - runtime->hw.formats = hinfo->formats;
> - runtime->hw.rates = hinfo->rates;
> - snd_pcm_limit_hw_rates(runtime);
> - snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> -
> - /* avoid wrap-around with wall-clock */
> - snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_TIME,
> - 20,
> - 178000000);
> -
> - if (chip->align_buffer_size)
> - /* constrain buffer sizes to be multiple of 128
> - bytes. This is more efficient in terms of memory
> - access but isn't required by the HDA spec and
> - prevents users from specifying exact period/buffer
> - sizes. For example for 44.1kHz, a period size set
> - to 20ms will be rounded to 19.59ms. */
> - buff_step = 128;
> - else
> - /* Don't enforce steps on buffer sizes, still need to
> - be multiple of 4 bytes (HDA spec). Tested on Intel
> - HDA controllers, may not work on all devices where
> - option needs to be disabled */
> - buff_step = 4;
> -
> - snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
> - buff_step);
> - snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
> - buff_step);
> - snd_hda_power_up(apcm->codec);
> - if (hinfo->ops.open)
> - err = hinfo->ops.open(hinfo, apcm->codec, substream);
> - else
> - err = -ENODEV;
> - if (err < 0) {
> - azx_release_device(azx_dev);
> - goto powerdown;
> - }
> - snd_pcm_limit_hw_rates(runtime);
> - /* sanity check */
> - if (snd_BUG_ON(!runtime->hw.channels_min) ||
> - snd_BUG_ON(!runtime->hw.channels_max) ||
> - snd_BUG_ON(!runtime->hw.formats) ||
> - snd_BUG_ON(!runtime->hw.rates)) {
> - azx_release_device(azx_dev);
> - if (hinfo->ops.close)
> - hinfo->ops.close(hinfo, apcm->codec, substream);
> - err = -EINVAL;
> - goto powerdown;
> - }
> + scoped_guard(mutex, &chip->open_mutex) {
> + azx_dev = azx_assign_device(chip, substream);
> + trace_azx_pcm_open(chip, azx_dev);
> + if (azx_dev == NULL) {
> + err = -EBUSY;
> + break;
> + }
> + runtime->private_data = azx_dev;
> +
> + runtime->hw = azx_pcm_hw;
> + if (chip->gts_present)
> + runtime->hw.info |= SNDRV_PCM_INFO_HAS_LINK_SYNCHRONIZED_ATIME;
> + runtime->hw.channels_min = hinfo->channels_min;
> + runtime->hw.channels_max = hinfo->channels_max;
> + runtime->hw.formats = hinfo->formats;
> + runtime->hw.rates = hinfo->rates;
> + snd_pcm_limit_hw_rates(runtime);
> + snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> +
> + /* avoid wrap-around with wall-clock */
> + snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_TIME,
> + 20,
> + 178000000);
> +
> + if (chip->align_buffer_size)
> + /*
> + * Constrain buffer sizes to be multiple of 128
> + * bytes. This is more efficient in terms of memory
> + * access but isn't required by the HDA spec and
> + * prevents users from specifying exact period/buffer
> + * sizes. For example for 44.1kHz, a period size set
> + * to 20ms will be rounded to 19.59ms.
> + */
> + buff_step = 128;
> + else
> + /*
> + * Don't enforce steps on buffer sizes, still need to
> + * be multiple of 4 bytes (HDA spec). Tested on Intel
> + * HDA controllers, may not work on all devices where
> + * option needs to be disabled
> + */
> + buff_step = 4;
> +
> + snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
> + buff_step);
> + snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
> + buff_step);
> + snd_hda_power_up(apcm->codec);
> + if (hinfo->ops.open)
> + err = hinfo->ops.open(hinfo, apcm->codec, substream);
> + else
> + err = -ENODEV;
> + if (err < 0) {
> + azx_release_device(azx_dev);
> + goto powerdown;
> + }
> + snd_pcm_limit_hw_rates(runtime);
> + /* sanity check */
> + if (snd_BUG_ON(!runtime->hw.channels_min) ||
> + snd_BUG_ON(!runtime->hw.channels_max) ||
> + snd_BUG_ON(!runtime->hw.formats) ||
> + snd_BUG_ON(!runtime->hw.rates)) {
> + azx_release_device(azx_dev);
> + if (hinfo->ops.close)
> + hinfo->ops.close(hinfo, apcm->codec, substream);
> + err = -EINVAL;
> + goto powerdown;
> + }
>
> - /* disable LINK_ATIME timestamps for capture streams
> - until we figure out how to handle digital inputs */
> - if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
> - runtime->hw.info &= ~SNDRV_PCM_INFO_HAS_WALL_CLOCK; /* legacy */
> - runtime->hw.info &= ~SNDRV_PCM_INFO_HAS_LINK_ATIME;
> - }
> + /*
> + * Disable LINK_ATIME timestamps for capture streams
> + * until we figure out how to handle digital inputs
> + */
> + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
> + runtime->hw.info &= ~SNDRV_PCM_INFO_HAS_WALL_CLOCK; /* legacy */
> + runtime->hw.info &= ~SNDRV_PCM_INFO_HAS_LINK_ATIME;
> + }
>
> - snd_pcm_set_sync(substream);
> - mutex_unlock(&chip->open_mutex);
> - return 0;
> + snd_pcm_set_sync(substream);
> + return 0;
>
> - powerdown:
> - snd_hda_power_down(apcm->codec);
> - unlock:
> - mutex_unlock(&chip->open_mutex);
> +powerdown:
> + snd_hda_power_down(apcm->codec);
> + }
> snd_hda_codec_pcm_put(apcm->info);
> return err;
> }
> --
> 2.25.1
>
prev parent reply other threads:[~2026-07-14 6:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 8:40 [PATCH v2 0/3] ALSA: hda: Use scoped_guard() for remaining manual mutex handling wangdich9700
2026-07-10 8:40 ` [PATCH v2 1/3] ALSA: hda/cs35l41: Use scoped_guard() for fw_mutex in cs35l41_hda_bind() wangdich9700
2026-07-10 8:40 ` [PATCH v2 2/3] ALSA: hda/cs35l56: Use scoped_guard() for irq_lock in cs35l56_hda_fw_load() wangdich9700
2026-07-14 6:09 ` Takashi Iwai
2026-07-10 8:40 ` [PATCH v2 3/3] ALSA: hda: Use scoped_guard() for open_mutex in azx_pcm_open() wangdich9700
2026-07-14 6:11 ` Takashi Iwai [this message]
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=87ldbeje1d.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=david.rhodes@cirrus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=tiwai@suse.com \
--cc=wangdich9700@163.com \
--cc=wangdicheng@kylinos.cn \
/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