The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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
> 

      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